Security Overview

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]
Hosting location: London, United Kingdom (see section 4)

1. Purpose of this Security Overview

This Security Overview explains the technical and organisational measures used to protect the website and service available at checkitquick.academicintelligence.co.uk, referred to as the Service.

The Service is used by schools, academy trusts, colleges and other educational organisations to help parents, guardians, carers and authorised users check, confirm, submit or update information held by the school about parents and child pupils.

The Service may connect to school systems, including iSAMS and MySchoolPortal single sign-on, where configured by the school.

This document is intended to help school leaders, IT teams, data protection officers, compliance teams and procurement teams understand:

• a. where the Service is hosted;
• b. what data is processed;
• c. how API keys and secrets are protected;
• d. what security measures are used;
• e. how access is controlled;
• f. how logging, monitoring and incident response work;
• g. what responsibilities remain with the school; and
• h. what questions schools should consider before enabling the Service.

2. Security Approach

We take a risk-based approach to security.

The Service is designed around the following principles:

• a. data minimisation — the Service is designed not to keep a permanent copy of parent or pupil records after the processing session, except where limited information is needed for logs, audit trails, support, backups, security or legal purposes;
• b. secure transmission — data is transmitted using encrypted connections where technically possible;
• c. credential protection — API keys, secrets and SSO configuration values are treated as sensitive security information;
• d. tenant separation — school accounts and configurations are logically separated;
• e. least privilege — access should be limited to authorised users and necessary permissions;
• f. UK hosting — the core application and primary database are hosted in London, United Kingdom;
• g. controlled support access — personnel access to customer data is limited to what is needed for support, maintenance and security;
• h. auditability — security, diagnostic and operational logs are maintained where appropriate; and
• i. shared responsibility — the school remains responsible for its own iSAMS, MySchoolPortal, administrator accounts, permissions and data governance.

The UK National Cyber Security Centre’s cloud security principles include data-in-transit protection, asset protection and resilience, separation between customers and governance. These principles are useful when assessing cloud-hosted services such as this one.

3. Service Summary

The Service may perform the following functions, depending on the school’s configuration:

• a. authenticate users through MySchoolPortal single sign-on;
• b. connect to iSAMS using API credentials provided by the school;
• c. retrieve relevant information from the school’s iSAMS database;
• d. display selected information to authorised users;
• e. allow parents, guardians, carers or authorised users to submit updates;
• f. validate or process submitted information;
• g. write approved or submitted changes back to iSAMS;
• h. store school configuration settings;
• i. store API keys, API secrets, SSO settings and related credentials;
• j. generate logs for security, troubleshooting and audit purposes; and
• k. provide support and maintenance.

The Service is not intended to act as a replacement school MIS or a permanent secondary database of parent or pupil records.

4. Data Hosting Location

The Service application is hosted on OVHcloud VPS infrastructure (OpenStack region os-uk2, London, United Kingdom).

The PostgreSQL database is provided by Neon with compute in AWS Europe West 2 (London), United Kingdom.

The core Service infrastructure is intended to keep school, parent and pupil processing within the United Kingdom.

Where third-party providers are used for hosting, infrastructure, security, monitoring, support, email or diagnostics, details are listed in our subprocessor information (Subprocessor list).

5. Data Processed by the Service

Depending on configuration, the Service may process the following categories of data.

5.1 School Configuration Data

This may include:

• a. school name;
• b. school identifier;
• c. administrator account details;
• d. iSAMS endpoint or connection settings;
• e. MySchoolPortal SSO configuration;
• f. workflow settings;
• g. feature settings;
• h. notification settings; and
• i. service preferences.

5.2 API Keys, Secrets and Integration Credentials

This may include:

• a. iSAMS API keys;
• b. iSAMS API secrets;
• c. API tokens;
• d. client identifiers;
• e. client secrets;
• f. MySchoolPortal SSO metadata;
• g. endpoint URLs; and
• h. other configuration values required for integration.

5.3 Parent, Guardian and Carer Data

This may include:

• a. name;
• b. address;
• c. email address;
• d. telephone number;
• e. contact preferences;
• f. emergency contact information;
• g. relationship to pupil;
• h. submitted corrections or updates; and
• i. other information made available by the school through iSAMS or related systems.

5.4 Pupil Data

This may include:

• a. pupil name;
• b. pupil identifier;
• c. school identifier;
• d. year group, form, class or house;
• e. linked parent, guardian or carer relationships;
• f. contact and household information; and
• g. other information made available by the school through iSAMS or related systems.

5.5 Technical and Security Data

This may include:

• a. IP address;
• b. browser and device information;
• c. timestamps;
• d. login events;
• e. session events;
• f. API request metadata;
• g. error logs;
• h. audit logs;
• i. security alerts; and
• j. diagnostic information.

6. Data Minimisation

The Service is designed to minimise the amount of personal data stored by us.

The Service normally retrieves parent and pupil data from the school’s iSAMS database only when needed for the relevant workflow.

The Service is designed so that it does not retain a permanent copy of full parent or pupil records after the processing session, except where limited data is required for:

• a. security logs;
• b. audit trails;
• c. troubleshooting;
• d. support;
• e. error handling;
• f. backup integrity;
• g. legal compliance;
• h. dispute resolution; or
• i. verifying that changes were submitted or processed.

Where logs or audit records contain personal data, access is restricted and retention is limited.

7. Data in Transit

The Service uses encrypted connections for browser access.

Public access to the Service is provided over HTTPS/TLS.

The ICO notes that all versions of SSL have known vulnerabilities and must not be used for public-facing HTTPS implementations.

Where technically supported by third-party systems, communication with iSAMS, MySchoolPortal and related systems should also use secure encrypted channels.

Schools should ensure that any iSAMS or MySchoolPortal endpoints configured for use with the Service are configured securely and made available only as required.

8. Data at Rest

The Service stores only the data required for operation, configuration, security, support and legal purposes.

Stored data may include:

• a. school account configuration;
• b. administrator account details;
• c. API keys and secrets;
• d. SSO settings;
• e. service settings;
• f. logs;
• g. audit records; and
• h. limited support or diagnostic records.

Where technically available and appropriate, data at rest is protected using encryption, managed cloud storage controls, database security controls or equivalent measures.

The ICO states that encryption is not mandated for every item of personal data, but it is specifically recognised as an example of an appropriate technical measure and can help protect stored personal information from unauthorised access.

9. API Key and Secret Protection

API keys, API secrets, SSO configuration values and related credentials are treated as sensitive security information.

The Service uses the following measures to protect them:

• a. credentials are stored only where necessary for the Service to function;
• b. credentials are not intended to be exposed publicly;
• c. credentials are not intended to be included in ordinary user-facing pages;
• d. access to credentials is restricted to authorised system processes and authorised personnel where required;
• e. full secrets should not be displayed back to administrators after saving, where technically feasible;
• f. credentials should not be intentionally written into logs;
• g. credentials are deleted or disabled when no longer required, subject to backups and lawful retention;
• h. credentials are protected using encryption at the application layer before persistence (ASP.NET Core Data Protection), with keys persisted alongside the application database under restricted access; and
• i. suspected credential compromise is treated as a security incident.

10. Administrator Access

School administrator access is limited to authorised users.

Administrators may be able to:

• a. configure school settings;
• b. enter or update API credentials;
• c. configure MySchoolPortal SSO settings;
• d. view service status;
• e. manage school workflows; and
• f. request support.

Schools are responsible for ensuring that only appropriate staff are appointed as administrators.

Schools should promptly remove administrator access when staff leave, change roles or no longer need access.

School administrators currently authenticate via Google sign-in where configured; multi-factor authentication is available through Google account security settings but is not separately mandated by the Service beyond that identity provider.

The NCSC provides guidance on using SaaS securely, including configuring and maintaining SaaS applications to reduce common attack risks.

11. Authentication and Single Sign-On

The Service may use MySchoolPortal single sign-on where configured by the school.

Single sign-on may provide identity information such as:

• a. user identifier;
• b. email address;
• c. name;
• d. role or group information;
• e. authentication status; and
• f. other SSO claims made available by the school or MySchoolPortal.

The school is responsible for configuring MySchoolPortal correctly and ensuring that only authorised users can authenticate.

We do not independently verify parental responsibility, guardianship, court orders, family restrictions, safeguarding restrictions or entitlement to access unless this is reflected in the school’s own systems and configuration.

12. Access Control and Least Privilege

Access to the Service and its data is controlled using a least-privilege approach.

This means:

• a. users should only access the data and functions they need;
• b. school administrators should only be given appropriate permissions;
• c. support access should be limited to authorised personnel;
• d. database or infrastructure access should be restricted;
• e. credentials should be available only to required application components; and
• f. access should be removed when no longer required.

The school is responsible for configuring iSAMS and MySchoolPortal permissions so that the Service only receives access to appropriate data and functions.

13. Tenant Separation

The Service is designed to separate one school’s data and configuration from another school’s data and configuration.

Tenant separation measures may include:

• a. school-specific configuration records;
• b. school identifiers;
• c. permission checks;
• d. access controls;
• e. logical separation in the application and database;
• f. restricted administrative access; and
• g. testing to reduce the risk of cross-school access.

No school should be able to access another school’s configuration, API credentials or data through normal use of the Service.

14. Personnel Access

Our personnel may access customer data only where necessary for legitimate purposes, including:

• a. providing technical support;
• b. investigating faults;
• c. maintaining the Service;
• d. improving security;
• e. responding to incidents;
• f. complying with legal obligations; or
• g. acting on documented customer instructions.

Personnel access is restricted to authorised individuals.

Personnel with access to customer data are subject to confidentiality obligations.

Where reasonably practicable, support and troubleshooting are performed using minimal, anonymised, redacted or test data.

15. Logging and Monitoring

The Service may create logs for security, reliability, diagnostics and audit purposes.

Logs may include:

• a. timestamps;
• b. school identifiers;
• c. administrator identifiers;
• d. user identifiers;
• e. IP addresses;
• f. device and browser details;
• g. authentication events;
• h. API request metadata;
• i. error messages;
• j. service events;
• k. change-submission metadata; and
• l. security events.

Logs are used to:

• a. investigate technical issues;
• b. monitor availability;
• c. detect suspicious activity;
• d. support schools;
• e. protect the Service;
• f. verify system behaviour; and
• g. maintain auditability.

Logs are not intended to store full parent or pupil records unless technically necessary for error handling, support or audit purposes.

Access to logs is restricted to authorised personnel.

Log retention is limited to the period reasonably required for security, support, audit and operational purposes.

Current log retention: typically between 30 and 180 days unless a longer period is temporarily needed for a security investigation (consistent with our Privacy Policy).

16. Backups and Resilience

The Service may use backups to support availability, recovery and resilience.

Backup measures may include:

• a. database backups;
• b. application configuration backups;
• c. infrastructure backup or restore points;
• d. secure storage of backups;
• e. restricted access to backups; and
• f. periodic backup testing where appropriate.

Backups may contain school configuration, API credentials, logs or limited personal data depending on the state of the system at the time of backup.

Backups are retained for a limited period.

Current backup retention: typically up to approximately 90 days unless operational needs require otherwise.

Backups are not used for ordinary access and are restored only where necessary for service continuity, security investigation, disaster recovery or legal requirements.

17. Vulnerability Management

We take reasonable steps to identify and address security vulnerabilities.

Measures may include:

• a. keeping frameworks and dependencies updated;
• b. applying security patches;
• c. monitoring security advisories;
• d. reviewing application changes;
• e. testing material changes before release;
• f. reviewing logs and error reports; and
• g. remediating identified risks based on severity.

18. Secure Development

We aim to follow secure development practices.

These may include:

• a. separating development and production environments where reasonably practicable;
• b. avoiding use of live school data in development unless necessary and authorised;
• c. reviewing code changes before deployment where feasible;
• d. testing authentication and permission-sensitive functionality;
• e. validating user input;
• f. protecting against common web application risks;
• g. using secure session handling;
• h. avoiding unnecessary logging of sensitive data; and
• i. applying updates and patches.

Developers and administrators should avoid copying parent, pupil or API secret data into local files, screenshots, emails or support tickets unless necessary for troubleshooting and appropriately protected.

19. Change Management

Changes to the Service are managed to reduce the risk of disruption or security issues.

This may include:

• a. planning material changes;
• b. testing updates before release;
• c. deploying changes in a controlled manner;
• d. monitoring after deployment;
• e. rolling back where necessary; and
• f. notifying schools of material changes where appropriate.

Security-impacting changes are reviewed with additional care.

20. Incident Response

We maintain a process for identifying, investigating and responding to security incidents.

A security incident may include:

• a. suspected unauthorised access;
• b. suspected compromise of API credentials;
• c. unauthorised disclosure of personal data;
• d. loss or corruption of service data;
• e. cross-school access risk;
• f. malware or malicious activity;
• g. significant vulnerability exploitation; or
• h. compromise of hosting, database, administrator or support accounts.

When an incident is identified, we aim to:

• a. assess the nature and severity of the incident;
• b. contain the issue where possible;
• c. preserve relevant evidence;
• d. investigate affected systems and data;
• e. mitigate harm;
• f. notify affected schools where required;
• g. support schools with their own assessment; and
• h. implement lessons learned.

Where an incident involves personal data processed on behalf of a school, we will notify the school in accordance with our Data Processing Agreement.

The ICO explains that personal data breaches may need to be reported depending on the risk to people’s rights and freedoms.

For practical steps and contacts, see our Breach notification process.

21. Personal Data Breach Notification

Where we become aware of a personal data breach affecting personal data processed on behalf of a school, we will notify the school without undue delay.

Our notification may include, where available:

• a. a description of the incident;
• b. the affected systems;
• c. the categories of data involved;
• d. the approximate number of affected users, if known;
• e. likely consequences;
• f. containment steps;
• g. mitigation steps;
• h. recommended actions for the school; and
• i. a contact point for further information.

Information may be provided in stages if the investigation is ongoing.

The school remains responsible for deciding whether it must notify the ICO, parents, pupils, staff or other parties where the school is the controller.

22. Data Deletion and Offboarding

When a school stops using the Service, we will delete or disable relevant school data in accordance with the applicable agreement.

This may include:

• a. school configuration;
• b. API credentials;
• c. SSO settings;
• d. administrator accounts;
• e. cached or temporary data; and
• f. other service records.

Some data may be retained where required for:

• a. security logs;
• b. audit records;
• c. support history;
• d. backups;
• e. legal compliance;
• f. accounting;
• g. dispute resolution; or
• h. establishment, exercise or defence of legal claims.

Retained data remains protected and is deleted when no longer required.

23. Subprocessors and Third-Party Providers

We use third-party providers to help host, operate, secure, support or maintain the Service.

We require subprocessors that process personal data on our behalf to use appropriate security measures.

A current subprocessor list is available at our Subprocessor list and static mirror /legal/subprocessor-list.html.

DPIA support materials for schools are in our DPIA Support Documentation (full text on the Service; introductory mirror at /legal/dpia-support-documentation.html).

24. International Transfers

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

Where third-party providers process personal data outside the United Kingdom, we use appropriate safeguards where required, such as:

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

Schools may request further information about international transfers where needed for their own due diligence.

25. Security Responsibilities of Schools

Security is shared between us and each school.

Schools are responsible for:

• a. selecting appropriate administrators;
• b. removing access when administrators leave or change role;
• c. securing school email accounts;
• d. securing MySchoolPortal accounts;
• e. securing iSAMS accounts;
• f. configuring iSAMS API permissions appropriately;
• g. avoiding excessive API permissions;
• h. rotating API keys and secrets where appropriate;
• i. revoking compromised credentials;
• j. reviewing submitted changes before relying on them where necessary;
• k. maintaining accurate school records;
• l. managing parental access and family restrictions;
• m. considering safeguarding implications;
• n. notifying us promptly of suspected compromise; and
• o. ensuring their use of the Service complies with internal policies and data protection law.

Schools should not provide API keys or secrets by ordinary email unless necessary and appropriately protected.

Schools should not share administrator login details.

Schools should test configuration before enabling the Service widely.

26. Recommended School Configuration Checklist

Before enabling the Service, schools should consider the following checklist.

• Confirm that the person configuring the Service is authorised.
• Review the Terms of Service, Privacy Policy, Cookie Policy, Data Processing Agreement, Data Retention & Deletion Policy and DPIA Support Documentation.
• Confirm whether a DPIA is required.
• Confirm the lawful basis for processing.
• Check parent, pupil and staff privacy notices.
• Configure MySchoolPortal SSO securely.
• Configure iSAMS API permissions using least privilege.
• Avoid exposing unnecessary iSAMS data fields.
• Check safeguarding and restricted-contact implications.
• Test the workflow with limited users first.
• Confirm who reviews submitted changes.
• Confirm how errors or disputed changes will be handled.
• Confirm support contacts.
• Confirm credential rotation and revocation procedures.
• Remove access for staff who no longer need it.

27. Security Limitations

No online service can be guaranteed to be completely secure.

The Service depends on:

• a. secure school configuration;
• b. secure administrator accounts;
• c. secure iSAMS permissions;
• d. secure MySchoolPortal settings;
• e. secure third-party providers;
• f. secure devices and browsers used by users;
• g. network availability; and
• h. accurate source data in school systems.

We are not responsible for security incidents caused by:

• a. compromised school accounts not caused by us;
• b. excessive permissions granted by the school;
• c. incorrect iSAMS configuration;
• d. incorrect MySchoolPortal configuration;
• e. unauthorised sharing of credentials by the school;
• f. malware or compromise on a user’s device;
• g. third-party provider outages or breaches outside our control; or
• h. use of the Service contrary to our documentation or agreements.

28. Security Contact

Security concerns, suspected vulnerabilities or suspected unauthorised access should be reported to:

Security contact: [email protected]
Privacy contact: [email protected]
Website: checkitquick.academicintelligence.co.uk

For security incidents, include Security incident in the email subject line. For vulnerability reports, include Security vulnerability in the subject line.

Please include as much detail as possible, including:

• a. the affected school or account;
• b. the date and time of the issue;
• c. the page or function involved;
• d. screenshots where safe to provide;
• e. relevant error messages;
• f. your contact details; and
• g. whether you believe personal data or API credentials may be affected.

Do not include API secrets, passwords or unnecessary personal data in ordinary email.

29. Vulnerability Disclosure

If you believe you have found a security vulnerability in the Service, please report it responsibly.

You must not:

• a. access, copy, modify or delete data that is not yours;
• b. disrupt the Service;
• c. perform denial-of-service testing;
• d. attempt social engineering;
• e. attempt physical attacks;
• f. publicly disclose the issue before we have had a reasonable opportunity to investigate; or
• g. use the vulnerability for any unlawful purpose.

We will review credible vulnerability reports and take appropriate action based on risk.

Vulnerability reporting email: [email protected]

30. Compliance Documentation

Schools may request reasonable security and compliance information for due diligence purposes.

Depending on the request, we may provide:

• a. this Security Overview;
• b. our Data Processing Agreement;
• c. our Privacy Policy;
• d. our Cookie Policy;
• e. our Terms of Service;
• f. subprocessor information;
• g. data flow summaries;
• h. hosting location information;
• i. retention information;
• j. incident response information; and
• k. responses to reasonable security questionnaires.

Some information may be provided under confidentiality restrictions where it could affect security, commercial confidentiality or other customers.

31. Data Protection by Design

The Service is designed to support data protection by design and by default.

This includes:

• a. minimising persistent storage of parent and pupil records;
• b. limiting use of personal data to school-authorised purposes;
• c. protecting API credentials;
• d. using UK hosting for the core application and database;
• e. restricting support access;
• f. maintaining audit and security logs;
• g. separating school tenants; and
• h. giving schools control over configuration and access.

The ICO says data protection by design and by default requires organisations to embed data protection into systems, services and processes from the design phase and throughout their lifecycle.

32. Procurement and assurance snapshot

The following summary is provided for school procurement and due diligence. It is illustrative of current practices and is not an exhaustive list of controls or a certification claim.

• Administrator access. School staff sign in with Google OAuth; additional MFA is not enforced by us beyond security features available on the administrator’s Google account and session cookies described in our Cookie Policy.
• Encryption and storage. Browser access uses HTTPS/TLS. The PostgreSQL database is hosted with Neon on AWS London; encryption at rest and infrastructure controls are provided as part of Neon/AWS managed services per their documentation.
• Secrets and credentials. School API keys and integration secrets are stored in the application database and are accessible only to the application under access controls described elsewhere in this overview. ASP.NET Core Data Protection keys are stored in PostgreSQL.
• Patching and updates. Security-related dependency and platform updates are applied through our normal release and deployment process to the production stack.
• Vulnerability handling. Credible reports are reviewed and prioritised by risk; contact details are in the Security Contact section.
• Penetration testing. We do not currently publish a third-party penetration test certificate or report; schools may request proportionate assurance information via [email protected].
• Backups and restore. Backups support disaster recovery and are not used for ordinary access; full restore tests are performed when we validate continuity arrangements (not on a fixed public schedule).
• Access review. Operational access to production systems is limited; we review access when onboarding tooling changes or responding to incidents.
• Non-production environments. Routine local or staging work uses synthetic or sandbox configuration; production pupil or parent data is not routinely loaded into development machines.

For a practical school-side checklist before go-live, see section 2.2 of our DPIA Support Documentation.

Schedule 1 — Current Security Controls

Schedule 2 — Data Retention Summary

Schedule 3 — Incident Severity Guide

Schedule 4 — School Due Diligence Answers

Where is the Service hosted?

The application runs on OVHcloud VPS in London (os-uk2). The PostgreSQL database is hosted with Neon in AWS Europe West 2 (London).

Does the Service permanently store parent and pupil records?

The Service is designed not to permanently store full parent or pupil records after the processing session, except where limited information is needed for logs, audit trails, support, troubleshooting, backups, security or legal purposes.

Does the Service store API keys or secrets?

Yes. The Service stores API keys, secrets and integration settings required to connect to school systems such as iSAMS and MySchoolPortal.

Are API keys and secrets protected?

Yes. API keys and secrets are treated as sensitive security information and are protected using access controls and application-layer encryption (ASP.NET Core Data Protection) before storage.

Who configures the API keys?

An authorised school administrator enters or configures the API keys and secrets.

Who controls iSAMS permissions?

The school controls iSAMS permissions and is responsible for ensuring that API access is appropriate and not excessive.

Does the Service use MySchoolPortal SSO?

Yes, where configured by the school.

Can one school access another school’s data?

No. The Service is designed to logically separate school accounts and prevent one school from accessing another school’s data through normal use.

Are logs kept?

Yes. Logs may be kept for security, support, diagnostics and audit purposes.

Are logs limited?

Logs are intended to be limited to what is necessary for security, support, diagnostics and audit purposes, and are not intended to store full parent or pupil records unless technically necessary.

What happens if there is a breach?

We will investigate, contain and mitigate the incident. Where the breach affects personal data processed on behalf of a school, we will notify the school without undue delay in accordance with our Data Processing Agreement.

Can schools request more information?

Yes. Use [email protected]; include a clear subject (for example Security vulnerability or Security incident) for security-related questions.

Schedule 5 — Website Short Version

checkitquick.academicintelligence.co.uk is hosted in London, United Kingdom (application on OVHcloud; database with Neon on AWS London). The Service connects to school systems, including iSAMS and MySchoolPortal where configured by the school, to help authorised users check and update school-held parent and pupil information. The Service is designed not to permanently store full parent or pupil records after the processing session, except where limited information is required for logs, audit trails, support, troubleshooting, backups, security or legal purposes. API keys, secrets and SSO settings required for integrations are stored securely and treated as sensitive security information. Access is restricted, school accounts are logically separated, and HTTPS/TLS is used for browser access. Schools remain responsible for configuring iSAMS and MySchoolPortal permissions appropriately and for managing their own administrator access.

This overview is illustrative of current practices and does not constitute a warranty of any particular certification or control implementation.

Last updated: 12 May 2026.