Incident Response Plan

This plan covers suspected unauthorised access, lost devices, exposed QR/profile access, account compromise, malware, accidental disclosure, data corruption, backup loss, and service outage. It must be reviewed with each participating school.

Emergency Record

• Incident lead:
• School contact:
• Privacy contact:
• Child-safety contact:
• Technical contact:
• Date and time detected:
• Person who detected it:
• Systems or schools affected:
• Immediate safety concern:

Do not place student names, QR tokens, passwords, or copied database contents in ordinary email or chat while coordinating the response.

1. Identify and Escalate

1. Record what was observed, when, and by whom.
2. Treat uncertainty as a reason to assess promptly, not to dismiss the report.
3. Notify the incident lead and the relevant school contact.
4. Escalate immediately when child safety, active account misuse, public data exposure, or destructive activity may be involved.

2. Contain

1. If needed, disconnect the host from the network without deleting evidence.
2. Stop the public reverse proxy or affected app process.
3. Disable affected accounts and revoke sessions.
4. Rotate exposed profile tokens, invitations, reset links, passwords, and secrets as applicable.
5. Preserve the current database, logs, configuration, and verified backup before repairs.
6. Do not restore over the live database until evidence and a safety copy exist.

3. Assess

1. Determine which schools, accounts, students, records, dates, and functions may be affected.
2. Establish whether information was accessed, changed, lost, disclosed, or merely at risk.
3. Check account audit logs, aggregate security events, reverse-proxy logs if approved, backups, and device history.
4. Assess likely harm and any school, contractual, insurance, regulatory, or legal notification requirements.
5. Obtain appropriate privacy/legal advice; the app does not decide whether an incident is notifiable.

4. Communicate

1. Use the school's approved communication lead.
2. Give affected people clear facts, protective steps, contact details, and correction options.
3. Do not speculate or identify unrelated students.
4. Record decisions about school leadership, families, insurers, law enforcement, ACSC, OAIC, or other notifications.

5. Recover

1. Correct the cause before reconnecting the service.
2. Patch the host, dependencies, operating system, and reverse proxy where relevant.
3. Restore only from a verified backup after a restore rehearsal.
4. Confirm access roles, secure cookies, trusted HTTPS, secrets, QR limits, and monitoring.
5. Test sign-in, school boundaries, QR profiles, check-in, backup, and health monitoring.
6. Reopen in stages and watch for recurrence.

6. Review

Within an agreed period:

1. Record the timeline, decisions, impact, recovery, and evidence retained.
2. Identify technical, policy, training, and support improvements.
3. Assign owners and due dates.
4. Confirm corrections or deletion reviews are completed.
5. Update this plan and run another rehearsal where the response changed.

Tabletop Rehearsal

Suggested scenario: a teacher reports that a lost tablet may still have an active session while the public QR profile host is receiving unusually high request volumes.

Record:

• rehearsal date and participants.
• time to identify the incident lead.
• containment actions chosen.
• evidence that would be preserved.
• school/privacy/child-safety escalation decision.
• recovery order.
• gaps found and owners.
• date all follow-up work was closed.

Reference: OAIC data breach response planning.