Information for your Data Protection Impact Assessment

Controller, processor and contacts

Controller

Your school or trust. You decide which pupils are included, which figures are produced and who at your school may see them.

Processor

iCT4 Limited, company number 8092834, registered in England and Wales. iCT4 processes attendance data only on your instructions and for no purpose of its own. No pupil data is used to train anything, sold, or shared with any other customer.

Data protection contact at iCT4

dpo@ict4.co.uk, which is monitored. Write here with any question about how your pupils' data is handled, to ask for a copy of a signed agreement, or to raise a concern. Post reaches us at iCT4 Limited, Trevenson House, Church Road, Redruth, Cornwall TR15 3PT.

What data the system holds

Everything here comes out of the attendance export your school already runs. Nothing is collected from a pupil or a parent directly, and nothing is bought in from anywhere else.

The lawful basis under Article 6, which is yours to record

For a maintained school or an academy the answer is normally Article 6(1)(e), a task carried out in the public interest, grounded in the duty to keep an attendance register under section 434 of the Education Act 1996 and the attendance regulations made under it. An independent school more often relies on Article 6(1)(f), legitimate interests, or on 6(1)(c) where a specific legal obligation applies. iCT4 cannot make that determination for you, for the same reason it cannot make the Article 9 one: it is the controller's, and it turns on facts about your school rather than about this product.

Sub-processors

The complete list of sub-processors engaged under Article 28. There are no others. No analytics, advertising or tracking of any kind runs on a page carrying pupil data. Each one is engaged under a written data processing agreement and acts only on iCT4 Limited's instructions, and iCT4 Limited remains responsible to your school for each of them.

The last row is the exception, and it is marked in the table. Your school's own Microsoft or Google tenant is not a sub-processor of iCT4 Limited: it is your own provider under your own existing agreement with them, and it is listed here for completeness because it is part of the picture your assessment covers.

Technical and organisational measures

In transit

HTTPS only, with HTTP Strict Transport Security set for two years and preloading requested, so a browser will not make a plain-text request to this site even once.

At rest

Every disk holding your data is encrypted with AES-256, and so is every scheduled backup. Encryption keys are generated per project and are themselves protected by keys held in hardware security modules validated to FIPS 140-2. These are controls of the hosting platform rather than of this application, and are published at supabase.com/security.

On the member of staff's own device

Nothing. Every page carrying pupil data is served with Cache-Control: private, no-store, so no pupil data is written to the browser's disk cache where a device backup or another user of the same machine could reach it. No pupil identifier appears in a web address, so none enters browser history or a server log, and pupil search runs on the server rather than by sending a list to the browser.

Who can see what

Every role is enforced inside the database itself. Where a role is refused a pupil, the database returns no record for that pupil, so the restriction holds however the request is made and does not depend on a particular screen behaving correctly. The complete role-by-role list is available to your administrator in the Admin area, under Users and permissions, and is covered by automated tests that run on every change to the system.

Signing in

Your own Microsoft 365 or Google Workspace account. No password is created or held by this product, so your own sign-in policy and your own multi-factor authentication apply. An invitation is matched against the organisation your identity provider asserts, not against the email domain, so a mistyped address cannot become access.

Unattended screens and session length

Three limits apply. In the page, you are signed out after 30 minutes with no activity, warned at 25 minutes with a button to stay signed in. Behind that, the platform ends any session idle for an hour, which is the limit that holds for somebody who has disabled JavaScript and so defeated the in-page timer. And every session ends after ten hours regardless of activity, so no sign-in outlives a school day. Refresh tokens are single-use with a ten-second reuse window, and a token presented twice outside it is treated as compromised and revoked.

Page-view counting on the public pages

Six public pages count page views through Vercel Web Analytics, so we can tell whether schools are finding the site: the front page, the price list, the answers page, this page, the enquiry form and the cookie policy. Those six are every page a visitor can reach without signing in, and it runs on those and nowhere else: not on your dashboard, not on any report, not on any screen that has ever shown a pupil. That is enforced twice, by where the component is mounted and by a check on the way out that refuses any address other than those six, so it holds even if somebody later moves it. It sets no cookie and reads nothing from the visitor's device. Vercel records the page address, the referrer, the country, and the browser and device type, and identifies a visit by a hash derived from the request which is discarded after 24 hours. No visitor is identifiable and nothing follows anybody between sites.

What is sent to the browser

The calculation engine stays on the server. Every figure in this product is worked out server-side and only the rendered result reaches the browser, so the DfE method, the parser that reads your export and the persistent-absence and penalty-notice logic are not in any file a browser downloads. The JavaScript that is sent to a browser is compressed and rewritten into a form that cannot readily be read, and no readable copy of the original is published alongside it.

Audit trail

Every import, every settings change, every access change, every report of pupil names that leaves the system, and every single pupil report opened, including anything iCT4 does. Your administrator reads it in the system. The pupil is recorded as a reference rather than a copied name, so erasing a pupil degrades every log entry about them to 'a pupil who has since been removed' with nothing left to purge.

iCT4 access to your data

Support access is off unless your school switches it on, and the setting is per school. While it is on, a session has a fixed expiry time, is limited to the same level of access as a senior leader, and includes none of the administrative functions: it cannot change a setting, change who has access, or delete anything. Every session is recorded in your own activity log, and switching support access off ends any session that is open at the time. iCT4 will always ask before requesting it.

International transfers

Where pupil data is stored

The United Kingdom. The database, the authentication service and any stored file are held in AWS region eu-west-2 (London). No pupil record is stored outside the United Kingdom.

Where pupil data is processed

The United Kingdom. Pages are rendered by serverless functions in region lhr1 (London), so pupil data is processed there in transit. Nothing relating to a pupil is processed outside the United Kingdom.

Request routing

Vercel's routing layer operates across its global network. The routing rule used by this product applies only to the public home page, in order to forward a sign-in callback to the correct address. It reads no cookie, queries no database and processes no pupil data.

Transfers outside the United Kingdom

Notification emails about accounts only. Messages are dispatched from Ireland and the account data of the email service is held in the United States, so a transfer to the United States takes place. What is transferred is a member of staff's work email address and the name of the school. No pupil name, pupil identifier or attendance figure is included in any message. The transfer is made under the UK Standard Contractual Clauses, being the EU clauses as amended by the UK Addendum, under a data processing addendum signed by iCT4. The email service is additionally certified under the EU-US Data Privacy Framework including the UK Extension.

Identity provider

Authentication takes place within your school's own Microsoft or Google tenant, under your school's existing agreement with that provider. No pupil data is transmitted to either.

Access within the school

These are the roles a school grants. The two statements below the table are enforced in the database and not only by the screens, so a role that is refused access to a pupil receives no record for that pupil even if the database is queried directly.

Governors and trustees. A governor or trustee never sees a pupil's name, on any screen or in any report. That is enforced by the database, not only by the pages: a governor asking the database directly gets no pupil rows at all.

Anybody employed outside the school. Anybody employed outside the school, such as an Education Welfare Officer commissioned from an independent company, holds access with an end date on it. When that date passes the account resolves to no role at all, and that is checked inside the database rather than by the screens, so it stops reading every table in the same moment. Somebody from outside the school can never be made an administrator, and every pupil report they open is in your activity log.

Rights, and how a request is answered

Access and rectification

Everything here originates in your MIS, so a correction made there arrives at the next import and replaces what was held. There is no separate copy for a family to correct.

Erasure, and when it does not apply

For a maintained school or an academy, the right to erasure usually does not reach attendance data. Article 17(3)(b) disapplies it where processing is necessary for a legal obligation or a public task, and keeping an attendance register is both. So a family asking a school to delete their child's attendance record is normally a request the school can decline, giving reasons. That is the school's determination to make and not ours, for the same reason the Article 9 conditions are. The rest of Article 17 continues to apply when the retention period ends, and the right to rectification under Article 16 always applies.

A record that should not be there

This is the case that arises in practice. A child from another school in a shared export, a duplicate, a test record, a pupil whose record should never have left your management information system. Tell us and we remove them completely, within five working days, and confirm when it is done. It is a job we carry out rather than a button in the product, so that it is logged and checked rather than one mis-click away. Everything goes: the pupil, every figure derived from them, and every individual session mark and lateness event including the copies of the unique pupil number those carry. Every entry in the activity log about them degrades to a reference to a pupil who has since been removed, because the log holds a reference rather than a copied name. A removal that leaves copies behind is not a removal.

Automated decision-making

None. The system forecasts who is likely to fall into persistent absence, and that forecast is shown to a person who decides what to do. Nothing acts on a child without a member of staff.

Retention after your contract ends

Attendance data is kept for up to 90 days after the date your contract ends, and is then deleted. Deletion is carried out by a person rather than by an automatic job on a date: our console lists every school past its retention date and how overdue it is, so a deletion that has not happened is visible rather than assumed. A copy may remain in an encrypted backup for up to seven days after that. The period is held against each school individually, so a different one can be agreed with iCT4 and recorded before you begin; the figure recorded for your own school is shown in the copy of this pack inside the system. Deletion removes the pupil records, the imported attendance data and the derived figures. Entries in the activity log remain, because they record what staff did rather than anything about a pupil, and each one then reads as relating to a pupil who has since been removed.

Personal data breaches

How quickly you hear

Within 48 hours of us becoming aware of a personal data breach affecting your data, to the contact your school has named, without waiting for our own investigation to finish. Where we cannot give you the whole picture inside 48 hours we give you what we have within that period and the remainder in stages as it is established.

Who tells the regulator

You do, and we do not. Notifying the ICO, and notifying the families affected, are the controller's decisions and the controller's notifications, because your school is the controller. What we owe you is the information and the help you need to make them inside the 72 hours Article 33 gives you. We will also never ask you to accept a restriction on your own reporting as a condition of being told.

The plan behind it

A written breach plan setting out how an incident is recorded, contained, assessed and notified, and who decides, held inside our ISO/IEC 27001:2022 management system and walked through against a scenario every year alongside the disaster recovery plan. We will send a summary on request. It is not published in full because it names individuals and describes how we detect and escalate.

Backups, and what can be recovered

Article 32(1)(c) concerns the ability to restore availability and access to personal data in a timely manner, and Article 35(7)(d) requires it to be recorded. The limitations are therefore set out here as well as in the agreement.

What is backed up, and where

The whole database, every day, by the hosting platform. Every backup is encrypted at rest with the same AES-256 encryption as the live database and is held in the same United Kingdom region, never copied elsewhere. Seven daily backups are kept.

What a failure would cost you

A re-import. Every attendance figure in the system is derived from an export your own MIS produced and your school uploaded, and those files stay with you, so attendance data can always be rebuilt from a source that was never ours. What could not be rebuilt that way is small and changes rarely: your targets and thresholds, staff permissions, and requests waiting to be approved. The daily backup schedule is set against that assessment.

How long a recovery takes

Two hours to restore a single school on its own, and four hours from the decision to restore to the whole service being usable again. The single school figure is measured rather than estimated: we rehearsed it in September 2026 against a school whose data had been deleted and whose settings had been changed, restored it in full and checked it, and the work took about thirty-five minutes. The objective is set above the measured time because the slowest step copies the whole database rather than a single school, and that step lengthens as more schools join. The rehearsal is repeated annually within our ISO/IEC 27001 management system, at the same time as the breach plan is tested. Where a school requires a shorter recovery time, it should be raised before adoption and we will confirm whether we can commit to it.

Restoring your school without touching anybody else's

We can. The likely incident is one school losing its own work rather than the platform failing. A copy of the previous night's backup is restored into a separate, isolated project; your school's records are taken out of that copy and written back; the copy is destroyed. No other school's data is read, moved or rolled back at any point, and no other school loses a minute of work. That is the difference between restoring a school and rolling the whole platform back to yesterday, which we would not do to you and would not do to anyone else on your behalf.

Independent assurance

Certifications

ISO/IEC 27001:2022, Cyber Essentials and Cyber Essentials Plus. Each one below links to the issuing body's own register rather than to anything of ours, so that each may be confirmed as current without reference to us. The ISO entry goes to IAF CertSearch, the International Accreditation Forum's register, which means the chain runs from the certificate to the certification body to their national accreditation body without a step that depends on us. Certificate numbers are not printed, here or in the agreement, because all three are reissued annually and a printed number goes out of date silently between reissues while a register does not.

The people who could reach it

Everyone at iCT4 is under confidentiality terms and takes data protection training. Staff with access to pupil data are additionally screened to BS 7858, the British Standard for screening people who work in a secure environment.

Your right to audit us

If the information we give you is not enough, your school may audit us on 30 days' written notice, once in any 12 month period, and in addition at any time after a breach affecting your data. An auditor you appoint signs a confidentiality undertaking first and may not be a competitor of ours. Article 28(3)(h) requires this and the agreement carries it.

Independent testing

Cyber Essentials Plus includes an independent external vulnerability test and an authenticated internal scan, carried out by a certification body rather than by us, and reassessed every year. Dependencies are scanned continuously and patched on a defined schedule. Where a school's own security review requires more than this, ask and we will set out what we hold and what is planned.

The data processing agreement

A data processing agreement under Article 28(3), generated for your school with your own retention period and your own named contacts filled in. It carries everything on this page as a term rather than as a statement, plus the security annex, the 48 hour breach clause, your audit right and the sub-processor list with its notice period.

Sign-up is not required in order to read it. A specimen of the full agreement, with the placeholders visible, is available on request from dpo@ict4.co.uk, so that it can be reviewed before a decision is taken.

Information for parents

The rest of this page is written for the person completing your school's data protection paperwork. This part is for you.

What is held about your child

Their name, year group and registration group, the attendance marks the school records for each session with the Department for Education code the school used, and the figures worked out from those marks. Depending on what the school includes in its export it may also hold whether the child has special educational needs, is eligible for free school meals, receives the pupil premium, or has English as an additional language.

Where it comes from

All of it comes from the school's own management information system, in a file the school itself exports and uploads. Nothing is collected from you, nothing is collected from your child, and nothing is bought in from anywhere else.

What is not done with it

It is not sold, it is not shared with anyone outside the school, and it is not used to train anything. No decision is taken about your child automatically: the system can flag that a child is at risk of falling behind on attendance, and a member of school staff decides what to do about it.

Who to ask

Your child's school, not us. The school decides what is held and why, and we hold it only on the school's instructions, so a request about your child has to be answered by them. If you send it to us we have to pass it on rather than answer it, which only uses up the school's own time limit for replying to you.

Enquiries made through this website

Everywhere else on this page your school is the controller and we are the processor. For the details you type into our enquiry form it is the other way round, so this is your Article 13 information rather than your school's.

Who the controller is for these details

We are. Everywhere else on this page your school is the controller and we are the processor. For the details you type into our enquiry form, that is the other way round: they are ours, we decide what to do with them, and this section is your Article 13 information.

What we ask for and why

Your name, your school, an email address, a telephone number if you give one, and whatever you write. We use it to answer you and to set up a trial if you ask for one. The lawful basis is legitimate interests: you wrote to us about a product and answering you is what you are expecting.

Where it goes

To our helpdesk, and nowhere else. It is not added to a marketing list, it is not sold, and it is not passed to anybody outside iCT4. You will not be emailed about anything other than your enquiry.

How long we keep it

Until the enquiry is finished with. If nothing comes of it we delete it once the conversation has clearly ended; if you become a customer it moves into your account record and is kept for as long as that is. Ask us to delete it at any point and we will, unless we are holding it because you are a customer. No fixed number of months has been set. The criteria above are given in its place, as Article 13(2)(a) provides for.