Breach Notification Process

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 and incident contact: [email protected] (include Security incident in the subject for urgent incidents)
Emergency contact: use the address above with a clear subject line; schools with a contractual out-of-hours path should follow that arrangement
Hosting location: London, United Kingdom

1. Purpose

This Breach Notification Process explains how Academic Intelligence Ltd, referred to as we, us or our, identifies, investigates, manages and notifies security incidents and personal data breaches relating to checkitquick.academicintelligence.co.uk, referred to as the Service.

The purpose of this process is to:

• a. protect schools, parents, guardians, carers, pupils and users;
• b. reduce harm caused by actual or suspected breaches;
• c. support schools in meeting their UK GDPR obligations;
• d. ensure timely notification to affected schools;
• e. preserve evidence;
• f. support regulatory assessment where required;
• g. improve the security of the Service; and
• h. meet our contractual and legal obligations.

1.1 How to report a suspected incident to us

Email [email protected] and include Security incident at the beginning of the subject line so we can prioritise triage.

We monitor this mailbox during normal UK business hours (Monday to Friday, excluding English public holidays, unless we agree otherwise with you in writing). We aim to send an initial acknowledgement within one UK business day for schools with a current paid subscription, and within two UK business days for other correspondents. Complex investigations take longer; acknowledgement does not confirm that a breach has occurred.

Schools with a separate contractual emergency or out-of-hours escalation path should follow that route in parallel where appropriate.

Please include, where it is safe and lawful to do so:

• a. the school or organisation name and, if known, your customer reference or domain;
• b. the date and time you became aware of the issue (with timezone);
• c. a short description of what happened and what is affected;
• d. affected URLs, user accounts or integration endpoints, if relevant;
• e. whether you believe personal data, credentials or iSAMS connectivity may be affected;
• f. any steps already taken (for example credential rotation); and
• g. contact details for follow-up (including out-of-hours if offered).

Do not include API secrets, passwords, unnecessary copies of pupil records, or other highly sensitive material in ordinary email. If we need secure transfer, we will agree an appropriate method.

2. Scope

This process applies to actual or suspected incidents affecting:

• a. the Service;
• b. the website at checkitquick.academicintelligence.co.uk;
• c. the Service database;
• d. school configuration data;
• e. API keys, API secrets, tokens or SSO settings;
• f. iSAMS integration data;
• g. MySchoolPortal single sign-on data;
• h. parent, guardian, carer or pupil data processed through the Service;
• i. administrator account data;
• j. logs, audit trails, support records or diagnostic information;
• k. hosting, infrastructure, monitoring, support or email systems used for the Service; and
• l. subprocessors used to provide the Service.

This process covers both:

• a. security incidents, which may or may not involve personal data; and
• b. personal data breaches, which involve personal data.

3. Roles and Responsibilities

3.1 Schools as Controllers

For parent, pupil and school personal data processed through the Service, the school, academy trust, college or other educational organisation is normally the controller.

The school is normally responsible for deciding:

• a. whether a personal data breach is reportable to the ICO;
• b. whether affected individuals must be told;
• c. what information should be included in any ICO notification;
• d. what information should be sent to parents, pupils, staff or other individuals;
• e. whether safeguarding, legal, insurance or internal governance steps are required; and
• f. whether any additional actions are needed in iSAMS, MySchoolPortal or other school systems.

3.2 Our Role as Processor

For parent, pupil and school personal data processed through the Service, we are normally the processor.

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

Our role is to:

• a. identify and investigate the incident;
• b. contain the incident where possible;
• c. assess affected systems and data;
• d. notify affected schools without undue delay;
• e. provide available information to help schools assess risk;
• f. provide updates as further information becomes available;
• g. support mitigation and remediation; and
• h. keep internal records of the incident.

3.3 Our Role as Controller

We may act as controller for our own business, security, support, billing, website, administrator and customer relationship data.

Where a breach affects personal data for which we are controller, we will assess whether we need to notify the ICO and/or affected individuals.

4. Definitions

4.1 Security Incident

A security incident is any actual or suspected event that may affect the confidentiality, integrity or availability of the Service, systems, credentials or data.

Examples include:

• a. suspected unauthorised access;
• b. attempted account compromise;
• c. malware;
• d. suspicious administrator activity;
• e. denial-of-service attack;
• f. vulnerability exploitation;
• g. misconfiguration;
• h. loss of availability;
• i. suspicious API activity;
• j. exposure of API credentials; or
• k. unusual data access patterns.

A security incident is not always a personal data breach.

4.2 Personal Data Breach

A personal data breach is a breach of security leading to accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data.

Examples include:

• a. unauthorised access to parent or pupil data;
• b. one school accessing another school’s data;
• c. exposure of API keys or secrets that could allow access to school data;
• d. sending personal data to the wrong recipient;
• e. loss of logs containing personal data;
• f. unauthorised changes to iSAMS records through the Service;
• g. accidental deletion or corruption of personal data;
• h. unauthorised disclosure of support screenshots;
• i. compromise of an administrator account leading to access to personal data; or
• j. compromise of a subprocessor system containing personal data.

5. Breach Notification Principles

We follow these principles:

• a. act quickly — incidents are assessed promptly;
• b. contain first — immediate action is taken to reduce harm where possible;
• c. notify affected schools without undue delay — schools need information quickly to assess their own duties;
• d. provide phased updates — not all facts may be known immediately;
• e. prioritise child safety and safeguarding — pupil data and school context are treated as sensitive;
• f. preserve evidence — logs and evidence are protected for investigation;
• g. minimise further exposure — data and credentials are protected during response;
• h. document decisions — records are kept even if an incident is not reportable; and
• i. learn and improve — remediation actions are tracked.

The ICO advises organisations to start a breach log as soon as a possible breach is discovered, even if it may not ultimately be reportable.

6. Breach Reporting Contact

Actual or suspected security incidents or personal data breaches should be reported to:

• Security contact: [email protected]
• Privacy contact: [email protected]
• Emergency contact: as above unless your agreement specifies another urgent path

Reports should include, where available:

• a. the affected school or account;
• b. the reporter’s name and contact details;
• c. date and time of discovery;
• d. date and time the incident may have started;
• e. affected page, system, account or integration;
• f. description of what happened;
• g. screenshots or error messages, if safe to provide;
• h. whether API keys, secrets or tokens may be affected;
• i. whether parent, guardian, carer, pupil or staff data may be affected;
• j. any actions already taken; and
• k. whether urgent safeguarding, school operational or legal concerns exist.

Do not send API secrets, passwords, unnecessary personal data or large datasets by ordinary email.

7. Incident Detection Sources

Incidents may be detected through:

• a. automated monitoring;
• b. application logs;
• c. hosting provider alerts;
• d. database alerts;
• e. error monitoring;
• f. school reports;
• g. administrator reports;
• h. parent or user reports;
• i. subprocessor notifications;
• j. vulnerability reports;
• k. suspicious support requests;
• l. unusual API activity;
• m. failed login patterns;
• n. unexpected iSAMS update behaviour; or
• o. internal review.

8. Immediate Response Steps

When an incident is reported or detected, we will take the following steps.

8.1 Log the Incident

We will create an internal incident record containing:

• a. incident reference number;
• b. date and time reported;
• c. person who reported it;
• d. systems potentially affected;
• e. schools potentially affected;
• f. initial description;
• g. initial severity;
• h. immediate actions taken;
• i. people assigned to investigate; and
• j. next review time.

8.2 Triage the Incident

We will assess:

• a. whether the incident is ongoing;
• b. whether personal data may be involved;
• c. whether API keys or secrets may be compromised;
• d. whether more than one school may be affected;
• e. whether parent or pupil data may be affected;
• f. whether special category data may be affected;
• g. whether iSAMS records may have been altered;
• h. whether MySchoolPortal authentication may be affected;
• i. whether a subprocessor is involved; and
• j. what immediate containment is required.

8.3 Contain the Incident

Containment steps may include:

• a. disabling affected accounts;
• b. disabling affected integrations;
• c. revoking sessions;
• d. rotating API keys or secrets;
• e. asking the school to revoke iSAMS credentials;
• f. blocking suspicious IP addresses;
• g. disabling affected features;
• h. taking affected services offline temporarily;
• i. restricting access to logs or systems;
• j. restoring secure configuration;
• k. isolating affected infrastructure; or
• l. contacting subprocessors for urgent action.

8.4 Preserve Evidence

We will preserve relevant evidence where reasonably possible, including:

• a. logs;
• b. timestamps;
• c. affected records;
• d. configuration history;
• e. API activity;
• f. authentication events;
• g. support tickets;
• h. email records;
• i. subprocessor notifications; and
• j. screenshots or system exports.

Evidence will be protected and access will be limited to authorised personnel.

9. Severity Classification

Incidents will be classified using the following guide. Severity may change as more information becomes available.

10. Assessment of Personal Data Impact

We will assess whether the incident involved:

• a. parent, guardian or carer data;
• b. pupil data;
• c. school staff data;
• d. administrator data;
• e. API keys, secrets or tokens;
• f. special category data;
• g. safeguarding, welfare, medical or family information;
• h. login or authentication data;
• i. IP addresses or device information;
• j. support records;
• k. audit logs; or
• l. billing or customer data.

We will also assess whether the incident caused or may have caused:

• a. unauthorised access;
• b. unauthorised disclosure;
• c. unauthorised alteration;
• d. unauthorised deletion;
• e. loss of availability;
• f. data corruption;
• g. identity risk;
• h. safeguarding risk;
• i. distress;
• j. financial risk;
• k. confidentiality risk; or
• l. risk to school operations.

11. Notification to Schools

11.1 When We Notify Schools

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

We may also notify a school where:

• a. a security incident may affect the school;
• b. API credentials may need to be rotated;
• c. school configuration may be unsafe;
• d. suspicious activity may relate to the school’s account;
• e. the school needs to take containment action; or
• f. the school may need to assess its own legal or safeguarding duties.

11.2 How We Notify Schools

Notification may be made by:

• a. email to the school’s nominated contact;
• b. email to the school administrator;
• c. email to the school’s data protection contact;
• d. telephone call for urgent incidents;
• e. dashboard notice; or
• f. another appropriate method.

For serious incidents, we will use reasonable efforts to contact the school promptly using available contact details.

11.3 What We Include in the Initial Notification

The initial notification may include:

• a. incident reference number;
• b. date and time of notification;
• c. summary of what happened;
• d. date and time discovered;
• e. affected systems or features;
• f. affected school account;
• g. categories of data potentially affected;
• h. categories of individuals potentially affected;
• i. whether API keys or secrets may be affected;
• j. whether iSAMS or MySchoolPortal may be affected;
• k. immediate containment steps taken;
• l. recommended actions for the school;
• m. whether the investigation is ongoing;
• n. contact details for further information; and
• o. when the next update is expected, if known.

11.4 Phased Updates

Not all facts may be available immediately.

We may provide information in phases as the investigation progresses.

Updates may include:

• a. confirmed cause;
• b. confirmed scope;
• c. number or approximate number of affected records;
• d. number or approximate number of affected individuals;
• e. risk assessment updates;
• f. remediation steps;
• g. recommended school actions;
• h. whether credentials should be rotated;
• i. whether users should be contacted; and
• j. closure summary.

The ICO recognises that full details may not be available within the initial reporting period and that further information can be provided as soon as possible.

12. Notification to the ICO

12.1 Where We Are Processor

Where we are processor for school-controlled personal data, the school is normally responsible for deciding whether to notify the ICO.

We will provide reasonable assistance to the school by supplying available information about the incident.

12.2 Where We Are Controller

Where we are controller for affected personal data, we will assess whether the breach is notifiable to the ICO.

A breach is generally notifiable to the ICO if it is likely to result in a risk to the rights and freedoms of individuals.

If notification is required, we will notify the ICO without undue delay and, where feasible, within 72 hours of becoming aware of the breach. The ICO says that if notification is later than 72 hours, reasons for the delay must be given.

12.3 Information for ICO Notification

Where we notify the ICO, or assist a school with notification, relevant information may include:

• a. the nature of the personal data breach;
• b. categories and approximate number of data subjects affected;
• c. categories and approximate number of personal data records affected;
• d. likely consequences;
• e. measures taken or proposed to address the breach;
• f. measures taken or proposed to mitigate adverse effects;
• g. contact details for further information; and
• h. reasons for any delay, if notification is made after 72 hours.

13. Notification to Affected Individuals

13.1 Where the School Is Controller

Where a breach affects school-controlled parent, pupil or school personal data, the school is normally responsible for deciding whether affected individuals must be told.

Affected individuals may include:

• a. parents;
• b. guardians;
• c. carers;
• d. pupils;
• e. emergency contacts;
• f. school staff; or
• g. administrators.

We will assist the school by providing available information about:

• a. what happened;
• b. what data may be affected;
• c. likely consequences;
• d. containment steps;
• e. recommended mitigation; and
• f. technical details needed for the school’s assessment.

13.2 Where We Are Controller

Where we are controller and the breach is likely to result in a high risk to individuals, we will communicate the breach to affected individuals without undue delay, unless an exemption or alternative measure applies.

The communication may include:

• a. what happened;
• b. what information was involved;
• c. likely consequences;
• d. steps we have taken;
• e. steps individuals should take;
• f. contact details; and
• g. where to obtain further information.

14. Special Considerations for Schools and Children’s Data

Because the Service may process children’s data, incidents involving pupil data must be treated with particular care.

Risk assessment should consider:

• a. the age of pupils;
• b. whether contact or address information was exposed;
• c. whether safeguarding, welfare, medical or family information was involved;
• d. whether separated-family or restricted-contact issues may be relevant;
• e. whether unauthorised changes were made to emergency contacts;
• f. whether unauthorised access could affect child safety;
• g. whether special category data was involved;
• h. whether the incident could cause distress or harm; and
• i. whether urgent school safeguarding action is needed.

Where safeguarding concerns may exist, the school should follow its own safeguarding procedures.

15. API Credential Breach Procedure

Because the Service stores API keys, secrets and integration credentials, suspected credential compromise is treated seriously.

15.1 Examples of Credential Incidents

Credential incidents include:

• a. API key exposed in logs;
• b. API secret sent by email;
• c. API secret viewed by unauthorised person;
• d. administrator account compromised;
• e. database or secret store accessed without authorisation;
• f. suspicious API calls;
• g. third-party compromise involving credentials;
• h. credentials accidentally committed to code repository; or
• i. credentials entered into a phishing page.

15.2 Immediate Actions

Where API credential compromise is suspected, we may:

• a. disable the affected integration;
• b. rotate credentials where we control them;
• c. ask the school to revoke and reissue iSAMS credentials;
• d. ask the school to review iSAMS audit logs;
• e. ask the school to review MySchoolPortal SSO logs;
• f. restrict administrator access;
• g. reset sessions;
• h. investigate suspicious API activity; and
• i. notify affected schools.

15.3 School Actions

The affected school may need to:

• a. revoke the affected iSAMS API key;
• b. create a new API key with least-privilege permissions;
• c. update the Service configuration;
• d. review iSAMS audit logs;
• e. review MySchoolPortal access logs;
• f. check whether records were viewed or changed;
• g. notify its DPO or data protection lead;
• h. assess whether ICO notification is required; and
• i. assess whether parents, pupils or staff must be informed.

16. iSAMS Record Integrity Incident Procedure

Where an incident may have caused incorrect, unauthorised or unintended updates to iSAMS, we will:

• a. identify affected school account or accounts;
• b. identify affected workflow or API action;
• c. identify time period of suspected issue;
• d. identify affected records where possible;
• e. suspend affected write-back functionality where appropriate;
• f. preserve relevant logs;
• g. notify the affected school;
• h. provide available information to help the school review iSAMS records;
• i. support rollback or correction where technically possible; and
• j. remediate the cause.

The school remains responsible for checking and correcting its own iSAMS records unless otherwise agreed.

17. Cross-School Access Incident Procedure

A suspected cross-school access incident is treated as Critical unless clearly shown otherwise.

Examples include:

• a. a school administrator seeing another school’s configuration;
• b. a parent seeing data from the wrong school;
• c. API credentials linked to the wrong school account;
• d. logs or support records mixed between schools; or
• e. update submissions written to the wrong iSAMS instance.

Immediate actions may include:

• a. suspending affected access;
• b. disabling affected integrations;
• c. blocking affected workflows;
• d. preserving logs;
• e. identifying all affected schools;
• f. notifying affected schools without undue delay;
• g. identifying affected individuals and records;
• h. correcting configuration;
• i. reviewing tenant separation controls; and
• j. implementing remedial safeguards before restoring access.

18. Subprocessor Breach Procedure

If a subprocessor informs us of a security incident or personal data breach, we will:

• a. record the notification;
• b. assess affected systems and customers;
• c. request relevant details from the subprocessor;
• d. determine whether Service data is affected;
• e. determine whether school data may be affected;
• f. notify affected schools without undue delay where required;
• g. coordinate containment and remediation;
• h. monitor subprocessor updates; and
• i. keep records of decisions and actions.

Where the subprocessor breach affects personal data for which a school is controller, the school will normally decide whether ICO or individual notification is required.

19. Internal Escalation

The following incidents must be escalated immediately to the Director, Security Lead or Data Protection Lead (or the person covering that role):

• a. confirmed or suspected unauthorised access to parent or pupil data;
• b. suspected API secret compromise;
• c. suspected cross-school data exposure;
• d. unauthorised iSAMS write-back;
• e. compromise of administrator access;
• f. compromise of hosting, database or secret storage;
• g. incident involving special category data;
• h. incident involving safeguarding risk;
• i. incident affecting multiple schools;
• j. ransomware, malware or destructive attack;
• k. suspected insider misuse;
• l. incident likely to attract regulatory, media or legal attention; or
• m. any incident rated High or Critical.

20. Internal Incident Team

For significant incidents, we may form an incident team including:

• a. incident lead;
• b. technical lead;
• c. customer communications lead;
• d. data protection lead;
• e. legal adviser, where needed;
• f. hosting or infrastructure contact;
• g. subprocessor contact; and
• h. senior decision-maker.

The incident lead is responsible for coordinating investigation, containment, communication, documentation and closure.

21. Breach Timeline

The following timeline should be followed where practicable.

21.1 First Hour After Discovery

• a. create incident log;
• b. assign incident owner;
• c. assess immediate risk;
• d. contain active threat where possible;
• e. preserve evidence;
• f. identify affected schools or systems;
• g. escalate if High or Critical;
• h. decide whether urgent school notification is needed; and
• i. disable affected functionality if necessary.

21.2 First 24 Hours

• a. continue investigation;
• b. confirm whether personal data is involved;
• c. confirm whether API credentials are affected;
• d. assess affected data categories;
• e. assess affected schools;
• f. send initial notification to affected schools where required;
• g. recommend school containment actions;
• h. contact subprocessors where relevant;
• i. document decisions; and
• j. prepare further updates.

21.3 24 to 72 Hours

• a. refine scope and impact assessment;
• b. provide updated information to affected schools;
• c. assist schools with ICO assessment where needed;
• d. assess whether we need to notify the ICO as controller;
• e. continue remediation;
• f. identify long-term fixes;
• g. prepare individual notification support where needed; and
• h. document reasons for any delay or uncertainty.

21.4 After 72 Hours

• a. provide further updates as needed;
• b. complete technical remediation;
• c. confirm whether credentials were rotated;
• d. confirm whether affected functionality is safe to restore;
• e. support school follow-up questions;
• f. complete incident report;
• g. conduct lessons-learned review; and
• h. update policies, controls or documentation where needed.

22. Risk Assessment Factors

When assessing risk, we consider:

• a. type of personal data involved;
• b. sensitivity of the data;
• c. whether children’s data is involved;
• d. whether special category data is involved;
• e. whether data was encrypted or otherwise protected;
• f. whether API credentials were exposed;
• g. whether the data was actually accessed;
• h. whether the recipient is trusted;
• i. whether data was recovered or deleted;
• j. number of people affected;
• k. number of schools affected;
• l. likelihood of misuse;
• m. possible distress;
• n. safeguarding impact;
• o. financial or identity risk;
• p. confidentiality impact;
• q. integrity impact, including incorrect school records;
• r. availability impact; and
• s. whether further harm is likely.

23. Breach Record Keeping

We will keep an internal record of incidents and personal data breaches.

Records may include:

• a. incident reference;
• b. date and time discovered;
• c. date and time reported;
• d. person who reported it;
• e. affected systems;
• f. affected schools;
• g. description of incident;
• h. categories of data affected;
• i. categories of individuals affected;
• j. approximate number of affected records;
• k. severity classification;
• l. containment actions;
• m. investigation steps;
• n. notifications sent;
• o. decisions not to notify and reasons;
• p. remediation steps;
• q. closure date; and
• r. lessons learned.

Records will be kept for six years unless a longer or shorter period is required by law, contract or legitimate business need.

24. Communications Rules

During an incident:

• a. communications should be accurate and not speculative;
• b. uncertain facts should be clearly marked as unconfirmed;
• c. schools should receive information needed to manage their own obligations;
• d. API secrets, passwords and unnecessary personal data should not be sent by ordinary email;
• e. affected schools should not be identified to other schools unless necessary and lawful;
• f. external communications should be approved by the incident lead;
• g. media enquiries should be handled only by the Director or designated spokesperson; and
• h. legal advice should be sought for serious incidents where appropriate.

25. Notification Template to School

Use this template for initial school notification.

26. Notification Template to ICO Where We Are Controller

Use this only where we are controller for the affected personal data.

27. Notification Template to Affected Individuals Where We Are Controller

Use this only where we are controller and individual notification is required.

28. Closure Report

A closure report should be completed for High and Critical incidents and may be completed for Medium incidents.

The closure report should include:

• a. incident reference;
• b. summary;
• c. root cause;
• d. timeline;
• e. affected systems;
• f. affected schools;
• g. affected data categories;
• h. affected individual categories;
• i. number or approximate number of affected records;
• j. containment actions;
• k. notifications made;
• l. decisions not to notify and reasons;
• m. remediation completed;
• n. remediation outstanding;
• o. lessons learned;
• p. policy or control changes;
• q. owner for follow-up actions; and
• r. closure approval.

29. Post-Incident Review

After significant incidents, we will conduct a review to identify improvements.

The review may consider:

• a. how the incident happened;
• b. whether detection was timely;
• c. whether containment was effective;
• d. whether school notification was timely;
• e. whether documentation was adequate;
• f. whether logs were sufficient;
• g. whether access controls need improvement;
• h. whether API credential handling needs improvement;
• i. whether tenant separation controls need improvement;
• j. whether subprocessors responded appropriately;
• k. whether staff need further training; and
• l. whether policies, contracts or technical controls need updating.

30. Testing and Review of this Process

This process should be reviewed at least annually and after any significant incident.

The review should confirm:

• a. contact details are current;
• b. school notification routes are current;
• c. subprocessors are current (Subprocessor list);
• d. escalation roles are current;
• e. templates remain accurate;
• f. legal references remain accurate;
• g. incident logging is effective; and
• h. lessons learned have been implemented.

Tabletop exercises or test scenarios may be used to check readiness.

Schedule 1 — Incident Log Template

Schedule 2 — School Action Checklist

When notified of a breach, a school may need to consider:

• Notify the school DPO or data protection lead.
• Notify the headteacher, COO, bursar, trust lead or senior leadership as appropriate.
• Review iSAMS audit logs.
• Review MySchoolPortal logs.
• Revoke or rotate API credentials.
• Disable affected administrator accounts.
• Check whether records were viewed, changed or deleted.
• Check emergency contact, medical, safeguarding or restricted-contact implications.
• Assess whether the breach is reportable to the ICO.
• Assess whether affected individuals must be informed.
• Record the incident internally.
• Preserve evidence.
• Contact insurers or legal advisers if appropriate.
• Decide whether temporary operational controls are needed.
• Confirm when credentials or integrations are safe to re-enable.

Schedule 3 — Examples of Reportable and Non-Reportable Scenarios

These examples are illustrative only. The school remains responsible for its own legal assessment where it is controller.

Example 1 — API secret exposed

An iSAMS API secret is accidentally exposed in a support message or log.

Likely action:

• a. treat as High or Critical;
• b. revoke or rotate the credential;
• c. review access logs;
• d. notify affected school without undue delay;
• e. school assesses ICO notification.

Example 2 — Parent sees another family’s data

A parent logs in and sees another pupil or family’s information.

Likely action:

• a. treat as Critical;
• b. disable affected access;
• c. preserve logs;
• d. identify affected records;
• e. notify school without undue delay;
• f. school assesses ICO and individual notification.

Example 3 — Failed login spike

There is a spike in failed login attempts but no evidence of unauthorised access or personal data compromise.

Likely action:

• a. treat as Low or Medium;
• b. monitor and block suspicious traffic if needed;
• c. record incident;
• d. notify school only if school-specific risk exists.

Example 4 — Unauthorised iSAMS update

An error causes incorrect updates to be written to iSAMS.

Likely action:

• a. treat as High or Critical depending on data and scale;
• b. suspend affected write-back;
• c. identify affected records;
• d. notify school without undue delay;
• e. support record review and correction.

Example 5 — Email sent to wrong school

A support email containing school-specific configuration or personal data is sent to the wrong school.

Likely action:

• a. ask recipient to delete and confirm deletion;
• b. assess data involved;
• c. notify affected school;
• d. record incident;
• e. assess further notification duties.

Schedule 4 — Public Website Summary

You can publish this short version on your security or legal page:

Last updated: 12 May 2026.