DPIA Support Documentation

Version: 1.0
Effective date: 12 May 2026
Website: checkitquick.academicintelligence.co.uk
Service provider: Academic Intelligence Ltd
Registered office: 60 Viceroy Court, 36 Dingwall Road, Croydon, England, CR0 2NG
Company number: 17204358 (Companies House)
Contact email: [email protected]
Privacy contact: [email protected]
Security contact: [email protected] (include Security incident in the subject for incidents)
Hosting location: London, United Kingdom

This document should be read together with our:

An introductory static mirror (summary and links) is at /legal/dpia-support-documentation.html; the complete document is on this page.

1. Purpose of this Document

This document provides data protection impact assessment support information for schools, academy trusts, colleges and other educational organisations considering use of checkitquick.academicintelligence.co.uk, referred to as the Service.

The purpose of this document is to help schools understand:

a. what the Service does;
b. what personal data may be processed;
c. what data is retained by the Service;
d. what data is not retained by the Service;
e. where the Service is hosted;
f. what systems the Service connects to;
g. what risks should be considered;
h. what mitigations are in place;
i. what responsibilities remain with the school; and
j. what information may be copied into the school’s own DPIA.

This document is intended to support, but not replace, the school’s own DPIA.

2. Important Note for Schools

The school, academy trust, college or educational organisation using the Service is normally the data controller for parent, pupil and school data.

Academic Intelligence Ltd is normally the data processor when processing parent, pupil or school data on behalf of the school through the Service.

The school remains responsible for deciding:

a. whether a DPIA is required;
b. who should complete and approve the DPIA;
c. the lawful basis for processing;
d. whether consultation with the DPO, staff, parents or others is needed;
e. whether the risks are acceptable;
f. whether additional school-side controls are needed; and
g. whether the Service should be enabled.

The Department for Education says a DPIA is needed under UK GDPR whenever processing of personal data is likely to result in a high risk to individuals’ rights and freedoms.

2.1 Data flow summary

The table below is a high-level description for DPIA annexes. It is not a network diagram.

Flow	Summary
Parent or staff browser ↔ CheckItQuick	HTTPS session to our web application (London-region hosting).
Parent or staff browser ↔ MySchoolPortal	SSO redirect and token exchange as configured by the school; identities issued by the school’s MySchoolPortal arrangement.
CheckItQuick ↔ iSAMS HTTP/API	Our service calls school-configured iSAMS endpoints using keys supplied by the school; data is processed for display and for approved write-back.
Parent submits change → CheckItQuick → iSAMS	Updates travel from the browser to our application, then to iSAMS when the workflow and school approvals allow.
Logs, configuration, credentials → Neon (PostgreSQL)	Operational database stores integration settings, secrets, admin accounts and log-related information — not an intentional copy of the full MIS.
Service emails → Brevo (and possibly Zoho Mail for support mailboxes)	Operational or notification email when schools enable features that send mail.
Subscription billing → Stripe	Payment and billing metadata when online billing is used.
Build/deploy → GitHub	Source control and CI metadata; production pupil databases are not stored in repositories.

2.2 Before enabling CheckItQuick — school checklist

We expect every school to complete its own analysis. The following checklist is a practical starting point:

Confirm the lawful basis (and Article 9 condition, if special category fields are exposed) for the exact workflow you enable.
Update the school’s privacy notice and other transparency information if parents, guardians or staff will use the Service in a new way.
Restrict iSAMS API permissions and field exposure through configuration to the minimum necessary for the workflow.
Decide whether special category or sensitive attributes should be exposed at all; avoid exposing them unless required.
Define who on the school side may approve data changes written back to iSAMS.
Test using non-production or limited records where possible before full rollout.
Nominate privacy and security contacts for incident and DPIA correspondence.
Plan offboarding and credential rotation if you stop using the Service.

3. Service Overview

The Service is a website used by schools to support checking, validating and updating information held in school systems.

The Service may connect to:

a. iSAMS, the school management information system;
b. MySchoolPortal, for single sign-on where configured;
c. Google Authentication, for Service user accounts (typically school administrators); and
d. hosting, database, security, support and operational systems used to run the Service.

The Service allows authorised school administrators to configure the connection between the Service and the school’s systems.

Depending on how the school enables the Service, end users such as parents, guardians or carers may authenticate through MySchoolPortal and access workflows the school has chosen to make available.

The Service stores:

a. API keys and secrets;
b. school URLs and integration URLs;
c. which school the configuration relates to;
d. Google-auth-linked user account details (administrator accounts);
e. user email addresses;
f. user role and permission information;
g. logs;
h. support records; and
i. business, billing or contract records where applicable.

The Service does not intentionally store parent or pupil records.

4. Intended Purpose of Processing

The intended purpose of the Service is to help schools manage and update school-held information by allowing authorised access to relevant school system workflows.

Depending on configuration, the Service may be used to:

a. connect securely to iSAMS;
b. support MySchoolPortal single sign-on;
c. allow authorised users to check information held by the school;
d. allow authorised users to submit updates;
e. write updates back to iSAMS where configured;
f. store the technical credentials needed for integration;
g. manage school administrator access;
h. provide support and troubleshooting; and
i. maintain security and auditability.

The Service is not intended to be a replacement school MIS.

The Service is not intended to create a separate retained database of parent or pupil records.

5. DPIA Screening Summary

Schools may use the following screening summary when deciding whether a DPIA is required.

Screening question	Suggested answer for school DPIA
Does the Service involve personal data?	Yes. The Service may temporarily access parent, pupil, school administrator and school system data. It also stores school configuration, API credentials, school URLs and Google-auth-linked user accounts.
Does the Service involve children’s data?	Yes. The Service may temporarily access pupil-related data from school systems, although it does not intentionally retain pupil records.
Does the Service involve a new system or technology?	Yes, for schools newly adopting the Service.
Does the Service connect to existing school systems?	Yes. It may connect to iSAMS, MySchoolPortal and Google Authentication.
Does the Service store parent or pupil records?	No, not intentionally. Parent and pupil records may be accessed transiently but are not intentionally retained.
Does the Service store credentials or secrets?	Yes. It stores API keys, secrets, URLs and SSO configuration needed to operate the integration.
Could misuse affect confidentiality or integrity of school records?	Yes. If credentials or configuration were misused, there may be risk of unauthorised access or unauthorised updates.
Is a DPIA recommended?	Yes. Because the Service may involve children’s data, school records, credentials and integration with MIS/SSO systems, a DPIA is recommended before use.

The ICO says a DPIA should begin early, before processing starts, and should assess risks and mitigations in a flexible but documented way.

6. Nature of Processing

The Service may perform the following processing operations:

a. receiving school configuration data;
b. storing school URLs and system endpoint URLs;
c. storing iSAMS API keys, secrets and related credentials;
d. storing MySchoolPortal SSO configuration where used;
e. storing Google-auth-linked user account details;
f. authenticating users;
g. authorising users against school configuration;
h. temporarily accessing parent or pupil data from iSAMS;
i. temporarily displaying relevant data to authorised users;
j. submitting or writing updates back to iSAMS where configured;
k. logging security, authentication and operational events;
l. troubleshooting technical issues;
m. responding to support requests;
n. maintaining backups; and
o. deleting or disabling school configuration and credentials when no longer required.

7. Scope of Processing

7.1 Systems Involved

The Service may involve:

a. checkitquick.academicintelligence.co.uk;
b. Service database hosted in London, United Kingdom;
c. iSAMS;
d. MySchoolPortal;
e. Google Authentication;
f. hosting provider (see Security Overview and Subprocessor List);
g. email or support providers, where used;
h. error logging or monitoring arrangements, where used; and
i. backup and security systems.

7.2 Users Involved

Users may include:

a. school administrators;
b. school IT staff;
c. school data protection staff;
d. school support staff;
e. parents, guardians or carers, if enabled;
f. pupils, if enabled by the school; and
g. authorised personnel of the Service provider for support and security.

7.3 Data Location

The website and primary application database are hosted in London, United Kingdom (application on OVHcloud; PostgreSQL with Neon on AWS Europe West 2, London). See our Security Overview.

The core Service infrastructure is intended to keep Service data in the United Kingdom. Some subprocessors may process limited personal data outside the UK (for example email or authentication services); see section 24 and our Subprocessor List.

8. Categories of Data Subjects

The Service may involve the following categories of individuals:

a. school administrators;
b. school staff;
c. parents;
d. guardians;
e. carers;
f. pupils;
g. emergency contacts, if temporarily accessed from iSAMS;
h. technical contacts; and
i. support contacts.

The Service intentionally retains only school configuration, credentials, user account, log, support and business data. It does not intentionally retain parent or pupil records.

9. Categories of Personal Data

9.1 Data Intentionally Stored by the Service

The Service intentionally stores:

a. school name or identifier;
b. school website URL;
c. iSAMS endpoint URL or integration URL;
d. MySchoolPortal URL or SSO configuration;
e. API keys;
f. API secrets;
g. API tokens or related credentials;
h. Google-auth-linked user email address;
i. Google account identifier or authentication identifier;
j. display name, if provided by Google authentication;
k. user role and permissions;
l. school association for each user;
m. account creation date;
n. last login date;
o. login/security logs;
p. configuration change logs;
q. support records; and
r. billing or contract records where applicable.

9.2 Data Temporarily Accessed but Not Intentionally Stored

Depending on school configuration, the Service may temporarily access:

a. parent names;
b. parent contact details;
c. guardian or carer details;
d. pupil names;
e. pupil identifiers;
f. year group, form, class or house;
g. family relationship details;
h. emergency contact details;
i. other data returned by iSAMS according to the school’s API permissions; and
j. submitted update values before being written back or discarded.

This data is not intentionally retained as a permanent record by the Service.

9.3 Special Category Data

The Service is not intended to retain special category data.

However, special category data may be temporarily accessible if the school’s iSAMS configuration or API permissions expose such data. This could include health, medical, dietary, disability, safeguarding or welfare information.

Schools should configure iSAMS API permissions to avoid exposing unnecessary special category data.

9.4 Criminal Offence Data

The Service is not intended to process criminal offence data.

Schools should not configure the Service to access criminal offence data unless this has been separately assessed and agreed.

10. Data Flow Description

Schools may copy this section into their DPIA.

An authorised school administrator creates or accesses a Service account. The administrator links their account using Google Authentication. The administrator configures the school’s Service settings. The administrator enters school URLs, iSAMS endpoint details, API keys, API secrets and/or SSO settings. The Service stores these configuration values so that the integration can operate. Where configured, a user authenticates through MySchoolPortal single sign-on or other authorised login route. The Service uses the configured school credentials to connect to iSAMS. The Service may temporarily retrieve relevant information from iSAMS. The Service may display relevant information to the authorised user. The user may submit updates or confirmations. The Service may write configured updates back to iSAMS. The Service does not intentionally retain parent or pupil records after the workflow. The Service retains only configuration, credentials, user account information, logs, support records and business records as described in our Data Retention & Deletion Policy. On termination, school configuration and credentials are deleted or disabled subject to backup, legal, security and audit retention.

11. Data Flow Diagram for Website Publication

School Administrator
        |
        | Google Authentication
        v
checkitquick.academicintelligence.co.uk
        |
        | Stores: school configuration, URLs, API keys/secrets,
        | Google-auth user email, role, logs
        |
        +------------------------+
        |                        |
        v                        v
      iSAMS              MySchoolPortal SSO
        |                        |
        | Temporary access       | Authentication / SSO claims
        | to school data         |
        v                        v
Authorised workflow / update process
        |
        | Updates may be written back to iSAMS
        v
School iSAMS database


Parent / guardian / carer (where the school enables this route)
        |
        | MySchoolPortal SSO (where configured)
        v
checkitquick.academicintelligence.co.uk
        |
        +--- same temporary iSAMS access and update paths as above ---+

12. Lawful Basis

The school is normally responsible for identifying the lawful basis for processing parent, pupil and school data.

Possible lawful bases for schools may include:

a. public task, where the school is exercising official authority or performing public education functions;
b. legal obligation, where processing is required for statutory school duties;
c. legitimate interests, where applicable to independent schools or certain administrative activities;
d. contract, where relevant to staff or service administration; and
e. consent only where genuinely appropriate and freely given.

The school should decide and document the correct lawful basis in its own DPIA and privacy notice.

The Service provider does not decide the school’s lawful basis for school-controlled data.

13. Necessity and Proportionality

Schools may use the following wording as a starting point.

The Service is considered necessary and proportionate because:

a. it supports accurate school records;
b. it allows authorised configuration by the school;
c. it reduces manual handling of updates;
d. it can reduce errors caused by rekeying data;
e. it supports use of existing school systems rather than creating a new permanent pupil database;
f. it does not intentionally retain parent or pupil records;
g. it stores only the configuration and credentials needed to operate;
h. it uses Google Authentication for administrator user accounts;
i. it supports secure integration with iSAMS and MySchoolPortal; and
j. it can be disabled by the school when no longer needed.

The school should confirm whether the specific deployment is necessary for its own needs and whether any less intrusive alternative is available.

14. Data Minimisation

The Service supports data minimisation by:

a. not intentionally storing parent records;
b. not intentionally storing pupil records;
c. storing only school configuration needed for the integration;
d. storing only API credentials required for operation;
e. storing only necessary Google-auth-linked user account information;
f. using logs for security and support rather than as a parent/pupil record store;
g. allowing school configuration to control what is exposed by iSAMS; and
h. deleting or disabling configuration and credentials after termination or valid request.

Schools should further minimise data by:

a. granting least-privilege iSAMS API permissions;
b. avoiding exposure of unnecessary fields;
c. avoiding exposure of special category data unless required;
d. limiting administrator accounts;
e. disabling unused workflows; and
f. removing access when no longer needed.

15. Retention Summary

The Service does not intentionally retain parent or pupil records.

Suggested retention summary for school DPIA (aligned with our published Data Retention & Deletion Policy):

Data category	Retained by Service?	Retention
Parent records from iSAMS	No, not intentionally	Not retained
Pupil records from iSAMS	No, not intentionally	Not retained
School name/identifier	Yes	Duration of school account, then up to 90 days after closure
School URLs / iSAMS URLs	Yes	Duration of school account, then up to 90 days after closure
API keys and secrets	Yes	Duration of school account; deleted or disabled within 30 days of closure or written deletion request
SSO configuration	Yes	Duration of school account; deleted within 90 days of closure or written deletion request
Google-auth user email	Yes	While authorised, then deleted or disabled within 90 days of removal or request
Google account identifier	Yes	While authorised, then deleted or disabled within 90 days of removal or request
User role/permissions	Yes	While authorised, then up to 90 days after removal
Login/security logs	Yes	180 days
Configuration audit logs	Yes	12 months
API connection logs	Yes	180 days
Error logs	Yes	90 days
Support records	Yes	24 months after closure of each support thread or ticket
Breach/incident records	Yes	6 years
Billing/accounting records	Yes, where applicable	6 years from the end of the relevant financial year (and related contractual records per our retention policy)
Backups	Yes	30 to 90 days depending on rotation (often up to about 90 days)

16. Hosting and Storage

The Service website and database are hosted in London, United Kingdom. See our Security Overview.

The Service may use third-party providers for hosting, database, authentication, email, support, monitoring, diagnostics, backups and security.

Subprocessors are listed in our Subprocessor List.

17. Security Measures

The Service uses or is intended to use the following security measures.

Area	Security measure
Hosting	Application on OVHcloud (London); PostgreSQL with Neon on AWS Europe West 2 (London)
Transmission	HTTPS/TLS for browser access; encrypted connections to integrated systems where technically supported
API credentials	Protected using access controls and application-layer encryption (ASP.NET Core Data Protection) before persistence; keys persisted with restricted access (see Security Overview)
User authentication	Google Authentication for Service administrator accounts; MySchoolPortal SSO where configured by the school for end-user workflows
SSO	MySchoolPortal SSO where configured by the school
Access control	User roles and school association controls
Tenant separation	School configuration logically separated
Logs	Security and operational logs retained per published schedules
Staff access	Access restricted to authorised personnel
Backups	Typically up to approximately 90 days unless operational needs require otherwise
Deletion	School configuration and credentials deleted/disabled on termination/request subject to retention exceptions
Incident response	Breach Notification Process in place
Data minimisation	No intentional retention of parent or pupil records
Administrator MFA	Available via Google account security settings where Google sign-in is used; not separately mandated by the Service beyond that identity provider

18. School-Side Controls Required

The school should implement the following controls before enabling the Service:

a. complete or review DPIA screening;
b. involve the school DPO or data protection lead;
c. confirm lawful basis;
d. update privacy notices if required;
e. confirm the authorised administrator;
f. configure iSAMS API permissions using least privilege;
g. avoid exposing unnecessary iSAMS fields;
h. avoid exposing special category data unless required;
i. configure MySchoolPortal SSO securely;
j. ensure Google accounts used for administration are secure;
k. enable MFA on administrator Google accounts where practicable;
l. limit administrator access;
m. test the workflow before rollout;
n. decide who reviews submitted changes;
o. set a process for disputed or incorrect updates;
p. maintain a process for revoking API credentials; and
q. remove access when staff leave or change roles.

19. Consultation

The school should decide whether consultation is required with:

a. Data Protection Officer;
b. IT lead;
c. senior leadership team;
d. safeguarding lead;
e. MIS manager;
f. bursar or operations lead;
g. parents or parent representatives;
h. pupils, where appropriate;
i. academy trust central team; and
j. legal advisers or data protection consultants.

The ICO includes “consider consultation” as one of the expected DPIA steps.

20. Risks and Mitigations

Schools may copy and adapt the following risk table into their own DPIA.

Risk	Possible impact	Likelihood before controls	Severity before controls	Mitigations	Residual risk (indicative)
API key or secret compromise	Unauthorised access to iSAMS data or unauthorised updates	Medium	High	Secure credential storage; restricted access; school credential rotation; least-privilege iSAMS permissions; breach process	Low to medium (school to confirm)
Excessive iSAMS permissions granted by school	Service may access more data than needed	Medium	High	School to configure least privilege; test integration; avoid unnecessary fields; periodic review	Low to medium
Wrong school configuration	Data could be retrieved from or written to wrong iSAMS instance	Low/Medium	High	School identifiers; configuration review; testing; tenant separation; audit logs	Low
Cross-school access	One school may access another school’s configuration or data	Low	High	Logical tenant separation; school association controls; testing; logging; incident response	Low
Google account compromise	Unauthorised administrator access	Medium	High	Google account security; MFA; role controls; remove access promptly; monitor login events	Low to medium
Parent/pupil data accidentally captured in logs	Unnecessary retention of personal data	Low/Medium	Medium	Avoid logging full records; log minimisation; retention periods; deletion/redaction where found	Low
Special category data temporarily exposed	Health, welfare or safeguarding information may be accessed unnecessarily	Low/Medium	High	Least-privilege iSAMS permissions; school field review; avoid exposing sensitive fields unless needed	Low to medium
Incorrect updates written to iSAMS	School records may become inaccurate	Medium	Medium/High	Testing; validation; school review process; audit logs; support process; rollback/correction process	Low to medium
Unauthorised user access via SSO misconfiguration	Parent/staff user may access inappropriate information	Medium	High	School manages MSP configuration; testing; access review; restricted workflows	Low to medium
Service outage	School workflow unavailable	Medium	Medium	UK hosting; backups; monitoring; support; school can use iSAMS directly	Low to medium
Support request includes unnecessary sensitive data	Personal data or secrets exposed in support channel	Medium	Medium/High	Support guidance; do not send secrets; redact data; delete unnecessary data	Low
Delayed deletion after school leaves	Credentials or configuration retained longer than needed	Low/Medium	Medium	Deletion policy; offboarding checklist; backup expiry; credential revocation by school	Low

21. Children’s Data Assessment

The Service may involve temporary access to pupil data from school systems.

The Service reduces risk to children by:

a. not intentionally retaining pupil records;
b. not using pupil data for advertising;
c. not using pupil data for behavioural tracking;
d. not using pupil data for profiling;
e. not selling pupil data;
f. not training AI models on pupil data;
g. limiting retained data to configuration, credentials, user accounts and logs;
h. relying on school-controlled iSAMS permissions; and
i. using school-controlled SSO where configured.

Schools should consider:

a. whether pupil data is visible to parents or users;
b. whether any sensitive fields are exposed;
c. whether safeguarding restrictions affect access;
d. whether separated-family or court-order issues are relevant;
e. whether pupil age affects transparency duties; and
f. whether privacy notices are clear enough for parents and pupils.

22. Safeguarding and Restricted-Contact Considerations

Schools should review whether use of the Service could affect:

a. separated parents;
b. restricted contacts;
c. court orders;
d. parental responsibility disputes;
e. safeguarding flags;
f. emergency contact accuracy;
g. medical information;
h. access by non-resident parents;
i. access by guardians or carers; and
j. access to household or family relationship information.

The Service provider does not independently verify parental responsibility, guardianship, legal restrictions or safeguarding context. The school remains responsible for ensuring that its iSAMS and MySchoolPortal configuration reflects the school’s safeguarding and access decisions.

23. Accuracy and Integrity

The Service may allow information to be submitted or written back to iSAMS.

Risks include:

a. incorrect updates;
b. malicious updates by an unauthorised user;
c. accidental overwriting of accurate information;
d. duplicate or inconsistent records;
e. updates made without sufficient review; and
f. reliance on unverified information.

Recommended controls:

a. test workflow before rollout;
b. decide whether updates require staff review;
c. keep audit logs;
d. review change history;
e. train staff;
f. define correction process; and
g. verify important records before relying on them for safeguarding, medical, emergency or legal purposes.

24. International Transfers

The core website and application database are hosted in London, United Kingdom.

If any subprocessors process data outside the UK, appropriate safeguards should be in place where required, such as:

a. UK adequacy regulations;
b. UK International Data Transfer Agreement;
c. UK Addendum to the EU Standard Contractual Clauses; or
d. another lawful transfer mechanism.

Schools should review the current Subprocessor List for any international transfer implications (for example transactional email, company email, payment processing or global authentication services).

25. Subprocessors

Schools should review the current Subprocessor List before enabling the Service.

Provider	Purpose	Location / notes
OVHcloud	Application runtime, networking, backups where configured on this infrastructure	OpenStack zone os-uk2; London (UK)
Neon (AWS)	Managed PostgreSQL	AWS Europe West 2 (London), UK
Brevo	Transactional email where used	EU-based processor; appropriate contractual terms
Zoho Mail	Company mailboxes / support correspondence	Per Zoho documentation; transfer mechanisms where applicable
Stripe	Payment processing where billing applies	Per Stripe DPA / SCCs where relevant
Google	Google Authentication for administrator accounts	Global service; governed by Google terms and privacy policy
GitHub	Source control / CI (code and metadata, not production pupil databases)	Per GitHub terms; production secrets not in repositories
iSAMS; MySchoolPortal	School systems (controller-directed)	As contracted by the school

26. Records and Auditability

The Service may keep logs and audit records for:

a. login events;
b. configuration changes;
c. API connection activity;
d. error handling;
e. security events;
f. support investigation; and
g. breach investigation.

Logs are not intended to store parent or pupil records.

Where parent or pupil data is accidentally captured in logs, it should be deleted, redacted or minimised where reasonably possible unless needed for investigation, legal or security purposes.

27. Deletion and Offboarding

When a school stops using the Service, the Service provider will normally:

a. disable school access;
b. disable user accounts linked to the school;
c. delete or disable stored API keys and secrets;
d. delete or disable SSO configuration;
e. delete school URLs and integration settings where no longer required;
f. retain only necessary logs, support, security, billing and legal records; and
g. allow backups to expire under the normal backup cycle.

The school should also:

a. revoke iSAMS API keys directly in iSAMS;
b. remove MySchoolPortal SSO configuration if no longer needed;
c. remove administrator permissions;
d. review its supplier register; and
e. update its own data protection records.

28. DPIA Decision Record Template

Schools may copy this section into their own DPIA.

Question	School response
Is a DPIA required?	[Yes/No]
Reason for decision	[Insert]
DPO consulted?	[Yes/No + details]
IT/security consulted?	[Yes/No + details]
Safeguarding lead consulted?	[Yes/No + details]
Lawful basis confirmed?	[Insert lawful basis]
Special category condition required?	[Yes/No + details]
Parent/pupil privacy notice updated?	[Yes/No]
iSAMS permissions reviewed?	[Yes/No]
MySchoolPortal SSO reviewed?	[Yes/No]
Google account security reviewed?	[Yes/No]
Residual risks accepted?	[Yes/No]
Approved by	[Name/role]
Approval date	[Date]
Review date	[Date]

29. DPIA Completion Template

29.1 Project Name

Use of checkitquick.academicintelligence.co.uk for iSAMS/MySchoolPortal-linked school data checking and update workflows.

29.2 Project Owner

[Insert school project owner]

29.3 Controller

[Insert school/trust name]

29.4 Processor

Academic Intelligence Ltd

29.5 Description of Processing

The school uses checkitquick.academicintelligence.co.uk to support checking, validating and updating school-held information. The Service connects to iSAMS using school-provided API credentials and may use MySchoolPortal SSO where configured. School administrator accounts are linked to Google Authentication.

The Service does not intentionally retain parent or pupil records. It stores school configuration, school URLs, iSAMS/API URLs, API keys/secrets, SSO settings, Google-auth-linked user account details, user email addresses, roles, logs and support records.

29.6 Purpose

To support accurate and efficient management of school-held parent, pupil and contact information, reduce manual handling, and enable authorised updates to school systems.

29.7 Data Subjects

Parents, guardians, carers, pupils, school staff, school administrators and authorised users.

29.8 Personal Data

Temporarily accessed: parent/pupil information made available by iSAMS according to school configuration.

Stored by the Service: school identity, school URLs, integration URLs, API credentials, SSO settings, Google-auth user email, Google identifier, roles, permissions, logs, support records and business records.

29.9 Special Category Data

Not intentionally retained by the Service. May be temporarily accessible if exposed through school iSAMS configuration. School should avoid exposing unnecessary special category data.

29.10 Lawful Basis

[Insert school lawful basis]

29.11 Necessity and Proportionality

The Service is necessary to support accurate record checking and efficient updates. It is proportionate because it avoids creating a permanent secondary copy of parent/pupil records and stores only the technical data needed for integration and account management.

29.12 Key Risks

a. API credential compromise;
b. excessive iSAMS permissions;
c. incorrect SSO configuration;
d. unauthorised administrator access;
e. accidental exposure of parent/pupil data in logs;
f. incorrect updates to iSAMS;
g. cross-school access;
h. special category data exposure; and
i. safeguarding or restricted-contact issues.

29.13 Key Mitigations

a. UK hosting;
b. HTTPS/TLS;
c. secure storage of API credentials;
d. no intentional retention of parent/pupil records;
e. least-privilege iSAMS permissions;
f. school-controlled SSO;
g. Google Authentication for Service administrator accounts;
h. role-based school association;
i. tenant separation;
j. logging and audit records;
k. retention/deletion policy;
l. DPA in place;
m. breach notification process; and
n. school-side testing and access review.

29.14 Residual Risk

[Low / Medium / High — to be completed by school]

29.15 Decision

[Approved / Approved with conditions / Not approved]

29.16 Review Date

[Insert date]

30. School Pre-Go-Live Checklist

Before enabling the Service, the school should:

Complete DPIA screening.
Consult the DPO or data protection lead.
Confirm lawful basis.
Check whether privacy notices need updating.
Review iSAMS API permissions.
Ensure unnecessary parent/pupil fields are not exposed.
Avoid exposing special category data unless needed.
Review MySchoolPortal SSO configuration.
Confirm Google account security for administrators.
Enable MFA on Google accounts where practicable.
Restrict administrator access.
Test with a limited group.
Confirm who reviews updates.
Define process for incorrect or disputed updates.
Check safeguarding/restricted-contact scenarios.
Confirm offboarding and credential revocation process.
Record DPIA approval.

31. Supplier Answers for School Questionnaires

Does the Service store parent or pupil records?

No. The Service does not intentionally store parent or pupil records. Parent or pupil data may be accessed temporarily during a workflow but is not retained as a permanent record.

What data does the Service store?

The Service stores school configuration, school URLs, iSAMS/API URLs, API keys/secrets, SSO configuration, Google-auth-linked user account details, user email addresses, roles, permissions, logs, support records and business records.

Where is the Service hosted?

The website and primary database are hosted in London, United Kingdom.

Does the Service use Google Authentication?

Yes. School administrator Service accounts are linked to Google Authentication and user email addresses.

Does the Service use MySchoolPortal?

Yes, where configured by the school for single sign-on.

Does the Service connect to iSAMS?

Yes, where configured by the school using school-provided API credentials.

Who provides the API keys?

An authorised school administrator provides or enters the API keys/secrets.

Who controls the iSAMS permissions?

The school controls iSAMS permissions and should apply least privilege.

Does the Service use pupil data for advertising?

No.

Does the Service sell data?

No.

Does the Service train AI models on school, parent or pupil data?

No.

Can the Service be disconnected?

Yes. The school can request deletion/disabling of configuration and credentials, and should also revoke relevant credentials directly in iSAMS and related systems.

32. Documents Available to Support DPIA

The following documents are available:

a. Privacy Policy;
b. Cookie Policy;
c. Terms of Service;
d. Data Processing Agreement;
e. Security Overview;
f. Breach Notification Process;
g. Data Retention & Deletion Policy;
h. Subprocessor List;
i. this DPIA Support Documentation; and
j. [email protected] for support contact information.

Schedule 1 — Short Website Summary

checkitquick.academicintelligence.co.uk supports schools with their DPIA process by providing information about data flows, hosting, retention, subprocessors, security controls and risks. The Service is hosted in London, United Kingdom. It does not intentionally retain parent or pupil records. It stores only the information needed to operate the integration, including school configuration, school URLs, iSAMS/API URLs, API keys/secrets, SSO settings, Google-auth-linked user accounts, user email addresses, logs and support records. Schools remain the controller for school, parent and pupil data and should complete their own DPIA before enabling the Service.

Schedule 2 — Copy/Paste DPIA Risk Table

Risk	Impact	Controls	Residual risk (school to confirm)
API key compromise	Unauthorised access to iSAMS or unauthorised updates	Secure storage, least-privilege permissions, credential rotation, breach process	[Insert]
Excessive iSAMS permissions	More data accessible than necessary	School permission review, field minimisation, testing	[Insert]
Google account compromise	Unauthorised admin access	Google security, MFA, access reviews, role controls	[Insert]
Misconfigured SSO	Wrong user access	School SSO testing, MSP configuration review, restricted access	[Insert]
Incorrect update to iSAMS	Inaccurate school record	Validation, audit logs, staff review, correction process	[Insert]
Accidental log capture	Unnecessary data retention	Log minimisation, retention limits, redaction/deletion	[Insert]
Special category exposure	Sensitive data accessed unnecessarily	Avoid exposing fields, least privilege, school review	[Insert]
Cross-school access	Confidentiality breach	Tenant separation, school association, testing, monitoring	[Insert]
Service outage	Workflow unavailable	Backups, hosting resilience, school can use iSAMS directly	[Insert]
Delayed deletion	Data retained longer than needed	Retention policy, offboarding checklist, backup expiry	[Insert]

Key DPIA Message for Schools

The Service does not intentionally retain parent or pupil records, but it stores highly sensitive integration credentials. The main operational risk is therefore not long-term storage of pupil data in the Service, but misuse, compromise or over-permissioning of API keys and school system access. Schools should prioritise least-privilege iSAMS configuration, secure administrator accounts, careful SSO setup and a clear change-review process for writes back to iSAMS.

Last updated: 12 May 2026.