Data Retention & Deletion Policy

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

1. Purpose of This Policy

This Data Retention & Deletion Policy explains how Academic Intelligence Ltd, referred to as we, us or our, retains and deletes data in connection with checkitquick.academicintelligence.co.uk, referred to as the Service.

The purpose of this Policy is to:

a. explain what data we retain;
b. explain what data we do not retain;
c. set retention periods for different data categories;
d. explain how deletion requests are handled;
e. explain what happens when a school stops using the Service;
f. reduce unnecessary storage of personal data;
g. protect API keys, secrets and configuration data; and
h. support compliance with UK data protection law.

2. Scope

This Policy applies to data processed or stored by the Service, including:

a. school account records;
b. school configuration data;
c. school website URLs and integration URLs;
d. iSAMS API keys, secrets and connection details;
e. MySchoolPortal or other single sign-on configuration details;
f. Google-authentication-linked user accounts;
g. administrator email addresses;
h. logs and audit records;
i. support records;
j. security records;
k. backup copies;
l. billing and customer records; and
m. records required for legal, accounting, security or dispute purposes.

This Policy should be read together with our:

3. Summary of Our Retention Position

The Service is designed not to store parent or pupil records.

We do not intentionally retain:

a. pupil names;
b. parent names;
c. parent addresses;
d. parent phone numbers;
e. parent email addresses from iSAMS, except where the same person is also an authorised Service user;
f. pupil addresses;
g. pupil medical information;
h. pupil safeguarding information;
i. pupil contact records;
j. family records;
k. emergency contact records; or
l. full copies of iSAMS parent or pupil records.

The Service stores only the data needed to operate the school integration and user access, including:

a. which school the configuration relates to;
b. school website or system URLs;
c. API keys and secrets;
d. single sign-on configuration values;
e. Google-authentication-linked user accounts;
f. user email addresses;
g. school administrator account information;
h. operational logs;
i. security logs;
j. support records; and
k. business records.

3.1 Indicative retention periods (operational categories)

The following table summarises typical periods for categories we control directly. Actual retention may vary where investigations, legal holds, backup cycles or statutory obligations require a different approach (see later sections).

Category	Typical period
Security and application logs	Typically 30–180 days unless a longer period is temporarily needed for a security investigation
Support records	Typically 12–24 months unless deletion is requested earlier and is lawful
Backup copies	According to backup rotation (typically up to approximately 90 days unless operational needs require otherwise)
API keys and secrets after school closure or written deletion request	Deleted or disabled within 30 days unless lawful retention applies
SSO configuration after school closure or written deletion request	Deleted within 90 days unless lawful retention applies
School configuration after termination	Removed in line with the Data Processing Agreement; allow for backup expiry and legal/security exceptions
Billing and accounting records	Up to approximately six years where UK requirements apply

4. Roles and Responsibilities

4.1 Schools as Controllers

For parent, pupil and school data held in iSAMS, MySchoolPortal or related school systems, the school is normally the data controller.

The school is responsible for deciding:

a. how long it keeps parent and pupil records in its own systems;
b. how iSAMS data is managed;
c. how MySchoolPortal data is managed;
d. whether parent or pupil data should be corrected or deleted from school systems;
e. how to respond to data subject requests about school records; and
f. how to comply with its own legal and statutory retention duties.

4.2 Our Role

We are normally a data processor where we temporarily access school-controlled data to provide the Service.

We are normally a data controller for our own business, website, account, support, security and customer administration data, including user accounts linked to Google authentication.

5. Data We Do Not Retain

The Service does not intentionally retain parent or pupil records.

Parent or pupil information may pass through the Service temporarily during a session or technical request, but it is not stored as a permanent record by us.

This means that when a school or user asks us to delete parent or pupil records, we will usually explain that we do not hold those records and that the request should be directed to the school.

If any parent or pupil personal data is accidentally captured in logs, support records or error reports, we will handle it in accordance with this Policy and delete or minimise it where reasonably possible.

6. Data We Retain

6.1 School Account and Configuration Data

We may retain:

a. school name;
b. school identifier;
c. school website URL;
d. iSAMS endpoint URL or integration URL;
e. MySchoolPortal URL or configuration details;
f. service settings;
g. school account status;
h. authorised administrator details;
i. configuration history; and
j. timestamps showing when configuration was created or updated.

6.2 API Keys, Secrets and Credentials

We may retain:

a. API keys;
b. API secrets;
c. API tokens;
d. client identifiers;
e. client secrets;
f. SSO metadata;
g. connection strings or endpoint configuration;
h. OAuth or OpenID Connect configuration values; and
i. other credentials needed for the Service to function.

These credentials are treated as sensitive security information.

6.3 User Account Data

User accounts are linked to Google authentication.

We may retain:

a. user email address;
b. Google account identifier or authentication identifier;
c. display name, if provided by Google authentication;
d. school association;
e. user role or permissions;
f. account creation date;
g. last login date;
h. account status; and
i. login or authentication audit records.

6.4 Logs and Audit Records

We may retain:

a. login logs;
b. security logs;
c. configuration change logs;
d. API connection logs;
e. error logs;
f. administrative action logs;
g. timestamps;
h. IP addresses;
i. browser or device information;
j. school account identifiers; and
k. user account identifiers.

Logs are intended to support security, troubleshooting, auditability and service reliability.

6.5 Support Records

We may retain:

a. support emails;
b. support tickets;
c. school contact details;
d. screenshots or technical details provided by the school;
e. troubleshooting notes;
f. issue history; and
g. resolution records.

Schools and users should avoid sending unnecessary parent, pupil, API secret or password information in support requests.

6.6 Billing, Contract and Business Records

We may retain:

a. school billing details;
b. invoices;
c. payment records;
d. purchase orders;
e. contracts;
f. order forms;
g. renewal records;
h. correspondence about the service relationship; and
i. accounting records.

7. Retention Schedule

The following retention periods apply unless a longer or shorter period is required by law, contract, security need, dispute, investigation or legitimate business requirement.

Data category	Retention period	Reason
Parent and pupil records from iSAMS	Not intentionally retained	The Service is not designed to store parent or pupil records
School name and school identifier	For the duration of the school account, then up to 90 days after closure	Account administration and offboarding
School website URL and integration URLs	For the duration of the school account, then up to 90 days after closure	Service configuration and offboarding
API keys and secrets	For the duration of the school account, then deleted or disabled within 30 days of closure or written deletion request	Security and offboarding
SSO configuration values	For the duration of the school account, then deleted within 90 days of closure or written deletion request	Authentication and offboarding
Google-authentication-linked user account	While the user is authorised, then deleted or disabled within 90 days of removal or request	Account administration and security
User email address	While the user is authorised, then up to 90 days after removal unless needed for logs, security or business records	Account administration and audit
User role and permission records	While the user is authorised, then up to 90 days after removal	Access control and audit
Login and security logs	180 days	Security monitoring and investigation (aligned with our Security Overview)
API connection logs	180 days	Troubleshooting and security
Configuration change logs	12 months	Audit, troubleshooting and security
Error logs	90 days	Debugging and reliability
Support records	24 months after closure of each support thread or ticket	Support history and dispute handling; records may consist of email, ticketing tools we use from time to time, or both
Breach/incident records	6 years	Legal, regulatory and audit purposes (Breach notification process)
Contracts and order forms	6 years after end of contract	Legal and limitation periods
Billing and accounting records	6 years from the end of the relevant financial year	Tax and accounting requirements
Backups	30 to 90 days depending on rotation (often up to about 90 days)	Service continuity and recovery
Marketing contact records, if any	Until opt-out or no longer needed	Relationship management

8. Deletion When a School Leaves

When a school stops using the Service, we will begin offboarding and deletion.

Unless a different period is agreed in writing, we will:

a. disable the school account;
b. disable access for school users;
c. delete or disable API keys and secrets stored in the Service;
d. delete or disable SSO configuration;
e. delete school website URLs and integration URLs where no longer needed;
f. delete school-specific configuration;
g. retain only records required for security, legal, accounting, audit or dispute purposes; and
h. allow backups to expire through the normal backup cycle.

We may ask the school to confirm whether the Service should be fully disconnected before deletion.

The school is responsible for revoking API credentials in iSAMS, disabling any related MySchoolPortal configuration, and removing any school-side access permissions.

9. Deletion of API Keys and Secrets

API keys, API secrets and related credentials are high-risk security information.

We will delete or disable stored API credentials when:

a. the school terminates the Service;
b. the school asks us to delete them;
c. the credentials are replaced;
d. the credentials are suspected to be compromised;
e. the credentials are no longer needed; or
f. we reasonably believe deletion is required for security.

Deletion from live systems should normally occur within 30 days of a valid request or account closure.

Copies may remain temporarily in backups until the normal backup cycle expires.

We recommend that schools also revoke or rotate credentials directly in iSAMS or the relevant third-party system.

10. Deletion of User Accounts

User accounts are linked to Google authentication and user email addresses.

A user account may be deleted or disabled when:

a. the school removes the user’s access;
b. the user leaves the school;
c. the school asks us to remove the user;
d. the user requests deletion, where applicable;
e. the account has been inactive for 12 consecutive months;
f. the school account is closed; or
g. the account presents a security risk.

Deletion may include:

a. removing the user’s active account;
b. removing Google authentication linkage;
c. removing school association;
d. removing role and permission records; and
e. removing profile details.

Some references to the user may remain in logs, audit records, support records, security records or legal records where retention is necessary.

11. Inactive Accounts

We may review inactive school and user accounts periodically.

If a school account has been inactive for 12 consecutive months, we may contact the school to confirm whether the account is still needed.

If we receive no response, we may:

a. suspend the account;
b. disable integrations;
c. delete or disable API credentials;
d. delete configuration data; and
e. close the account.

If a user account has been inactive for 12 consecutive months, we may disable or delete it, subject to school instructions and operational needs.

12. Backups

Backups are used for service continuity, disaster recovery and security resilience.

Backups may include:

a. school configuration;
b. user account data;
c. school URLs;
d. API credentials;
e. logs;
f. support-related data if stored in backed-up systems; and
g. other operational data.

Backups are not used for ordinary access.

When data is deleted from live systems, it may remain in backups until the relevant backup expires or is overwritten.

Backup retention is normally 30 to 90 days depending on rotation.

If a backup must be restored, deleted data may temporarily reappear. Where this occurs, we will take reasonable steps to re-apply deletion where appropriate.

13. Logs and Audit Records

Logs and audit records help us protect the Service, investigate issues and support schools.

Logs may include personal data such as:

a. user email address;
b. Google authentication identifier;
c. IP address;
d. browser or device information;
e. school account identifier;
f. timestamp; and
g. administrator action.

Logs should not intentionally contain parent or pupil records.

If parent or pupil data is accidentally captured in logs, we will delete, redact or minimise it where reasonably possible, unless retention is necessary for security, legal, audit or incident investigation purposes.

14. Support Tickets and Emails

Support records may be retained to help resolve issues, maintain continuity, defend claims and improve the Service.

Support records should not include:

a. passwords;
b. full API secrets;
c. unnecessary parent data;
d. unnecessary pupil data;
e. safeguarding information; or
f. large exports from iSAMS.

If a school sends unnecessary sensitive information to us, we may delete, redact or ask the school to resend the request without unnecessary data.

Support records are normally retained for 24 months after the support request is closed.

15. Business and Legal Records

Some records are retained for legal, accounting, contractual and business reasons.

These may include:

a. contracts;
b. order forms;
c. invoices;
d. payment records;
e. tax records;
f. customer correspondence;
g. legal notices;
h. complaints; and
i. dispute records.

These records are normally retained for six years after the end of the relevant contract, financial year or dispute.

16. Deletion Requests

Individuals may have the right to ask for their personal data to be erased in certain circumstances. The UK Information Commissioner’s Office explains that the UK GDPR right to erasure is not absolute and applies only in particular situations; see ico.org.uk.

Deletion requests should be sent to the privacy contact: [email protected].

A request should include:

a. the requester’s name;
b. email address;
c. school name, if relevant;
d. description of the data to be deleted;
e. whether the request relates to a school account, user account or support record; and
f. any information needed to verify identity or authority.

We may need to verify the requester’s identity before acting.

17. Requests About Parent or Pupil Records

We do not intentionally retain parent or pupil records.

If a parent, guardian, carer, pupil or staff member asks us to delete parent or pupil information held in iSAMS or another school system, we will normally direct them to the school.

This is because the school controls those records.

Where we have accidentally captured parent or pupil data in support records, logs or error reports, we will review the request and delete or redact the data where appropriate.

18. Requests from Schools

A school may request deletion of:

a. its school account;
b. school URLs;
c. integration configuration;
d. API keys and secrets;
e. SSO configuration;
f. administrator accounts;
g. support records, where appropriate; and
h. other school-specific operational data.

We may ask the school to confirm the deletion request in writing.

We may refuse, delay or limit deletion where retention is necessary for:

a. security;
b. legal compliance;
c. accounting;
d. dispute resolution;
e. fraud prevention;
f. incident investigation;
g. audit;
h. enforcement of our agreements; or
i. establishment, exercise or defence of legal claims.

19. Secure Deletion Methods

Deletion may involve:

a. deleting records from live databases;
b. disabling accounts;
c. removing access permissions;
d. deleting secrets from secret storage;
e. deleting or redacting support records;
f. removing configuration values;
g. anonymising records;
h. allowing backups to expire; and
i. deleting data from third-party systems where technically possible and within our control.

Where deletion is not technically possible or would compromise security, audit integrity or legal obligations, we may restrict access, anonymise, redact or retain the data until deletion becomes possible.

20. Anonymisation and Aggregation

We may anonymise or aggregate data so that it no longer identifies a person or school.

Anonymised or aggregated data may be retained for:

a. service improvement;
b. statistics;
c. security analysis;
d. performance monitoring;
e. product planning; or
f. business reporting.

We will not treat genuinely anonymised data as personal data.

21. Suspension Instead of Deletion

In some cases, we may suspend or disable data rather than immediately delete it.

This may happen where:

a. a school has not confirmed final termination;
b. there is an active dispute;
c. there is an unpaid invoice;
d. there is a security investigation;
e. the account may need to be restored;
f. legal retention applies; or
g. deletion would interfere with audit or incident records.

Suspended data will be access-restricted and retained only as long as necessary.

22. Subprocessors and Third-Party Providers

Where data is processed by subprocessors or third-party providers, deletion may depend on their systems and retention cycles.

Subprocessors may include:

a. hosting providers;
b. database providers;
c. email providers;
d. support ticket providers;
e. error monitoring providers;
f. security providers;
g. Google authentication services;
h. iSAMS; and
i. MySchoolPortal.

Further detail is listed in our Subprocessor list.

Where a deletion request affects data stored with a subprocessor under our control, we will take reasonable steps to ensure deletion is completed in accordance with this Policy and our contracts.

Schools remain responsible for deletion from systems they control, including iSAMS, MySchoolPortal and school Google accounts.

23. Google Authentication Data

User accounts are linked to Google authentication.

We may store information received from or associated with Google authentication, such as:

a. user email address;
b. Google account identifier;
c. display name;
d. authentication timestamp; and
e. school account association.

If a user’s Google account is deleted or disabled by the school or Google, this does not automatically guarantee deletion of all records in the Service.

The school or user may need to request deletion separately.

When a Service user account is deleted, we will remove the active Google authentication linkage from the Service, subject to retention of logs, audit records, security records and legal records.

24. Review of Retention Periods

We will review this Policy and our retention periods periodically.

Reviews may consider:

a. whether data is still needed;
b. whether retention periods remain proportionate;
c. legal or regulatory changes;
d. security requirements;
e. customer requirements;
f. technical feasibility;
g. backup cycles; and
h. incident or support needs.

This Policy should be reviewed at least annually.

25. Contact

Questions or requests about retention and deletion should be sent to:

Academic Intelligence Ltd
Privacy contact: [email protected]
Security contact: [email protected]
General contact: [email protected]
Registered office: 60 Viceroy Court, 36 Dingwall Road, Croydon, England, CR0 2NG
Company number: 17204358 (Companies House)
Website: checkitquick.academicintelligence.co.uk

Schedule 1 — Retention Table for Website Publication

Data	Do we store it?	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 + up to 90 days
School website URL	Yes	Duration of school account + up to 90 days
iSAMS/API endpoint URL	Yes	Duration of school account + up to 90 days
API keys and secrets	Yes	Duration of school account; delete/disable within 30 days of closure or request
SSO configuration	Yes	Duration of school account + up to 90 days
Google-auth user email	Yes	Duration of authorised access + up to 90 days
Google account identifier	Yes	Duration of authorised access + up to 90 days
User role/permissions	Yes	Duration of authorised access + up to 90 days
Login/security logs	Yes	180 days
Configuration audit logs	Yes	12 months
Support tickets/emails	Yes	24 months
Breach/incident records	Yes	6 years
Billing/accounting records	Yes, where applicable	6 years
Backups	Yes	30 to 90 days

Schedule 2 — School Offboarding Checklist

When a school leaves the Service, we will normally:

confirm the closure request;
disable school access;
disable user accounts linked to that school;
delete or disable stored API keys and secrets;
delete or disable SSO configuration;
delete school URLs and integration configuration;
retain only necessary logs, support, security, billing and legal records;
allow backups to expire under the normal backup cycle; and
confirm completion if requested.

The school should also:

revoke iSAMS API keys directly in iSAMS;
remove or disable MySchoolPortal SSO configuration if no longer needed;
remove school-side administrator permissions;
check that no unwanted access remains; and
update its own supplier and data protection records.

Schedule 3 — Internal Deletion Checklist

For internal operational use.

Step	Complete?
Confirm requester identity/authority	[ ]
Confirm school/account affected	[ ]
Confirm data categories requested for deletion	[ ]
Check whether parent/pupil data is actually held	[ ]
Delete/disable school account if requested	[ ]
Delete/disable user account if requested	[ ]
Delete/disable API keys and secrets	[ ]
Delete/disable SSO configuration	[ ]
Delete school URLs and integration settings	[ ]
Review support records for unnecessary data	[ ]
Review logs where practical and proportionate	[ ]
Note backup expiry period	[ ]
Check legal/accounting/security retention exceptions	[ ]
Record decision and action taken	[ ]
Confirm completion to requester where appropriate	[ ]

Schedule 4 — Short Website Summary

Last updated: 12 May 2026.