Process and implementation draft — not legal advice and not a claim that deletion is implemented. Use this guide to design, approve, build and verify deletion before public account creation or store submission. Current operating boundary: Prototype — fictional demonstration data only.

Document Control

1. Current Implementation — Review Requests Only

The current product does not delete accounts or data.

What exists:

• /account-deletion is a public information page;
• a signed-in secure account can submit a review request in Global Settings;
• the requester chooses account-only or account-and-school-review and may add a note;
• only one open request is allowed per account;
• an Administrator can change the request to requested, reviewing, completed, denied or cancelled; and
• creation and status changes are written to account audit logs.

What does not exist:

• no external unauthenticated request form or verified email workflow;
• no identity-verification or authorised-representative workflow;
• no automatic session, role or account deletion;
• no school-workspace or student-record deletion engine;
• no provider/subprocessor deletion orchestration;
• no backup-suppression or restore reconciliation process;
• no deletion receipt showing item-level outcomes; and
• no guarantee that marking a request completed means anything was technically deleted.

Until the execution and evidence steps in this guide are implemented, Administrators must not mark a request completed merely because it was reviewed.

2. Five Different Actions Must Not Be Confused

A user asking to “delete my account” is not automatically asking or authorised to erase every school record they created. Conversely, disabling an account is not account deletion.

3. Legal and Policy Baseline

There is no single unlimited deletion right that overrides school records, public-records, tax, security or other lawful retention requirements.

The final process must identify the applicable framework:

• Queensland Government agencies must comply with the Information Privacy Act 2009 (Qld), QPPs, public-records requirements and other applicable law. A contracted service provider must follow the approved arrangement and promptly assist the agency.
• An organisation covered by the Commonwealth Privacy Act 1988 must apply the APPs. APP 11 generally requires reasonable steps to destroy or de-identify personal information no longer needed, unless lawful retention applies.
• Store policies add product requirements when a mobile app supports account creation, but they do not authorise deletion of school records contrary to law.
• The approved school retention schedule and service agreement must decide document control, return, retention and disposal. “The school owns all data” is not a sufficient legal analysis.

Where retention is required, keep only the minimum required data, restrict its use/access, record the authority and expiry trigger, and explain it to the requester.

4. Request Channels Required Before Public Accounts

In-app channel

The account settings must contain a prominent deletion action for every account type that can be created. It may require reauthentication and a clear confirmation, but must not use unnecessary friction or force a person to telephone support.

External channel

Provide a public, durable HTTPS URL that lets a former or locked-out user initiate deletion without reinstalling or signing in. The current /account-deletion page is informational only and does not yet satisfy this requirement.

The external path needs:

• service/operator identity;
• accessible request form or equivalent monitored intake;
• secure identity verification after intake;
• authorised-representative and child/family handling;
• acknowledgement and case reference;
• explanation of scope, subscriptions and likely retention;
• status/contact path; and
• protections against enumeration, spam and fraudulent deletion.

Do not ask a requester to put passwords, full student records, identity documents or QR tokens into an ordinary email.

5. Request Types and Scope Questions

At intake, ask the minimum questions needed to distinguish:

• staff account deletion;
• removal from one or more schools;
• school workspace closure/transfer;
• a student record access/correction/disposal request;
• QR card revocation;
• deletion of a support or uploaded item;
• objection to a particular use; and
• subscription cancellation, which is separate from account deletion.

Confirm in writing what the requester is asking. Do not make school-data deletion the default consequence of closing an individual teacher account.

6. Identity and Authority Verification

Use proportionate verification based on risk and the existing relationship.

Staff account holder

• reauthenticate an active session or use an approved verified recovery channel;
• check recent account changes, compromise indicators and active school roles;
• never rely only on an email address typed into the request; and
• pause and use the incident process if account takeover is suspected.

Sole Administrator or school owner

Before deletion:

• identify another authorised Administrator or the school’s formal successor;
• transfer billing, school ownership, recovery and operational contacts;
• resolve exports and records custody; and
• ensure deleting the account will not strand the workspace, backups or support obligations.

If transfer cannot be authorised, escalate to the school/legal owner; do not improvise ownership.

Student or family request

Student records currently do not use student accounts. Route the request to the accountable school and verify the requester’s identity, relationship and authority under the school process. A parent/carer request is not automatic authority to receive every record, and a child’s privacy and safety interests must be considered.

Do not use the public QR token or four-digit code as sufficient identity for a formal data request.

Authorised representative

Record the representative’s identity, scope of authority and how it was verified. Collect no more identity evidence than necessary, store it separately with restricted access, and dispose of it under the request-record schedule.

7. Intake and Triage Workflow

1. Create a unique case and record channel, date, request type and minimum contact details.
2. Acknowledge receipt and explain the next step, expected target and urgent support path.
3. Verify identity/authority through a separate secure step.
4. Identify every relevant school, account, student, provider and subscription.
5. Immediately contain any security issue; deletion must not erase incident evidence.
6. Place only the necessary disposal hold so routine retention jobs do not create inconsistent results.
7. Notify the accountable school/privacy/records owner where school information is involved.
8. Decide the applicable law, contract, record schedule and store policy.
9. Give the requester a confirmed scope and ask for clarification only where material.
10. Record an accountable decision owner and due date.

The service target [insert] must not be presented as a legal deadline until approved. Security and data-breach reporting must be immediate even while deletion scope is being assessed.

8. Data Discovery Checklist

Search by internal identifiers after identity is verified; avoid broad searches by personal details where possible.

Account and access data

• app_users identity, credential hash/salt and account status;
• user-school roles;
• web and native account sessions;
• native sign-in handoffs;
• invitations, email-verification and password-reset tokens;
• account recovery-readiness and account audit records;
• teacher practice profile and associated results; and
• notification or support records linked to the user.

School and teaching records

• school profile, subscription entitlement and billing-owner references;
• students, schedules, attendance, progress, pass-offs, practice and reports;
• lesson summaries and Daily Review records;
• records showing who created, approved or corrected an action; and
• exports held under school control.

These records usually require a separate school decision; they do not disappear because a teacher account closes.

Public/student access data

• profile access token and hashed student security code;
• active/expired QR sessions;
• friend links;
• public practice-timer runs and tracking preference;
• student sight-reading/practice results; and
• security/rate-limit events.

Operational copies

• primary SQLite database;
• encrypted and unencrypted backups, if any;
• temporary restore copies and pre-restore safety backups;
• server, reverse-proxy, security and support logs;
• monitoring/incident systems;
• administrator downloads and exports;
• provider/subprocessor copies; and
• local device/native secure-session material.

Record locations searched, query/version, date, person and result. Absence from the primary table does not prove absence from every controlled copy.

9. Decision Matrix

Complete one row for every discovered data class.

Valid outcomes include delete, de-identify, correct, transfer, retain under restriction, or refuse a specific request with reasons. “Denied” without a data-class analysis is not adequate.

10. Technical Execution Order

The production deletion job should be idempotent, auditable and resumable without logging deleted personal information.

1. Confirm approval and snapshot only the minimum evidence needed to prove the decision.
2. Cancel or transfer subscription ownership separately; explain store-managed billing.
3. Revoke all account sessions, handoffs, verification/reset tokens and outstanding invitations.
4. Remove active school roles and ownership references after approved transfer.
5. Revoke affected QR sessions/tokens where within scope.
6. Delete or de-identify account-only profile, preference and result data as decided.
7. Null, replace or retain creator/reviewer references according to the schema and audit decision.
8. Delete/de-identify other live records approved for disposal in dependency-safe transactions.
9. Instruct every provider/subprocessor to delete or restrict its copies and obtain evidence.
10. Record a non-sensitive deletion receipt containing case ID, action classes, timestamps, code version, success/failure and approver—not the deleted data.
11. Verify through independent queries that no active credentials, roles, sessions or prohibited copies remain.
12. Notify the requester of the outcome and remaining retention.

Mark the case complete only after verification. A partial failure remains reviewing or a dedicated failure state in the future workflow, with an owner and retry plan.

11. Schema and Audit Design Requirements

Before automating deletion, inspect foreign-key behaviour for every related table. Required design principles include:

• account deletion must not cascade into school records merely because a teacher created them;
• historical actions that must remain should use a neutral/de-identified actor reference where lawful;
• current role and session data should not survive account deletion;
• deletion-request records must not retain the full email indefinitely by default;
• account audit logs currently contain optional user ID and email and need an approved de-identification/retention rule;
• request free text must be minimised and redacted where it contains unnecessary information;
• school deletion requires a separately authorised, whole-workspace dependency map; and
• tests must use fictional data and cover retries, partial failures and restoration.

Do not rely on database cascade rules alone; provider copies, files, caches, exports and backups sit outside them.

12. School Workspace Closure

Closing a school is a governed project, not an account checkbox.

Required decisions:

• who has authority to close or transfer the workspace;
• which official system receives required records;
• export format, encryption, recipient and confirmation;
• when staff, QR and native access are revoked;
• treatment of shared/global Method Book metadata;
• active incidents, complaints, swaps, invitations and support cases;
• subscription cancellation and financial records;
• backup and restore-copy expiry;
• provider return/deletion certificates; and
• post-closure contact for access/correction requests.

Require two-person approval or equivalent governance for destructive whole-school actions. Keep a recoverable pre-action copy only if the approved retention and security plan allows it.

13. Student Record Disposal and De-identification

Student discontinuation currently preserves the profile/history; it is not deletion. A deletion review must distinguish current status, correction, transfer, retention and disposal.

Before deleting or de-identifying a student record:

• confirm the school’s authority and recordkeeping obligations;
• identify shared attendance, pass-off, group, report, friend and leaderboard effects;
• revoke profile token, security code and public sessions immediately if access should end;
• protect other students’ records and audit history;
• decide whether aggregate statistics remain genuinely de-identified; and
• test that names, initials, instrument, class, rare results and linked IDs cannot reasonably re-identify the child in the retained dataset.

Simply replacing a name with “Anonymous” while preserving linkable school and event records is not automatically de-identification.

14. Backups and Restoration After Deletion

Deleting a row from the live database does not remove it from existing backups.

The approved process must state:

• backup retention period and expiry mechanism;
• whether deletion from individual backup archives is technically possible and safe;
• when a retained backup is placed beyond ordinary use;
• who may restore it and for what purpose;
• how a restored database reapplies completed deletions before returning to service;
• how temporary restore copies are destroyed; and
• how deletion and expiry are evidenced without retaining the deleted content.

Implement a minimal deletion-suppression/reconciliation ledger or equivalent protected process before relying on old backups after production deletions. Test a full restore: a deleted account must not silently become active again.

15. Providers, Native Clients and User-held Copies

The operator must send authenticated deletion instructions to every provider that holds in-scope data and verify completion. A provider’s generic retention page is not case evidence.

For native clients:

• revoke server-side sessions;
• remove locally stored session credentials on next contact/sign-out where possible;
• explain any device-level action needed if the device is offline; and
• verify that app caches contain no durable school content outside the approved design.

The operator may not be able to delete an export already lawfully downloaded by a school or a screenshot taken by a user. The outcome must distinguish operator-controlled copies from customer/user-held records, and the school must apply its own disposal process.

16. Subscriptions and Payments

Account deletion does not necessarily cancel an Apple, Google or direct subscription. Before payments are enabled:

• show subscription status and billing channel before confirmation;
• give the correct cancellation/manage-subscription link;
• offer immediate account deletion even if cancellation timing differs, subject to lawful retention;
• avoid charging an unusable deleted account through a direct billing system;
• retain only required transaction evidence; and
• explain refund/consumer-law rights without “no refunds” wording.

No payment provider is currently enabled, so these are release requirements rather than current behaviour.

17. Outcome Notice

The completion notice should state in plain language:

• case reference and completion date;
• confirmed request scope;
• account/access actions performed;
• data classes deleted or de-identified;
• data retained, reason, access restriction and expiry trigger;
• provider and backup treatment;
• subscription status/cancellation responsibility;
• any action the requester must take; and
• privacy complaint/review contact.

Do not include password hashes, tokens, internal security details, third-party personal information or a full data dump in the notice.

18. Refusal, Partial Completion and Complaints

If all or part of a request cannot be completed:

• identify the specific data class;
• cite the approved legal, contractual or records reason;
• consider correction, de-identification, restricted retention or role removal as appropriate;
• provide the retention trigger/period, not “kept as long as necessary” alone;
• identify the decision maker; and
• explain internal review and external complaint options.

For Queensland Government agency information, direct the requester through the school/Department privacy process. Current Queensland guidance requires the agency to receive the complaint first and allows at least 45 business days before an unresolved complaint is taken to the OIC. For APP-covered organisations, OAIC guidance generally requires complaint to the organisation first and treats 30 days as a usual reasonable response period.

19. Security and Child-safety Exceptions

A deletion request that reveals account compromise, unauthorised access, coercion or risk to a child must be escalated immediately. Contain the risk and preserve only the evidence needed for investigation; do not erase evidence merely to close the deletion case.

Communications with a child or family must use the school’s safe, authorised pathway. The public deletion form must not become an unmoderated messaging channel or expose whether a named child exists in the service.

20. Apple and Google Store Gate

If a native app supports account creation:

Apple

Apple requires users to be able to initiate deletion in the app. The option must be easy to find and offer deletion of the whole account and associated data not lawfully required to be retained; deactivation alone is insufficient. A manual process may take time if the user is clearly informed and later receives confirmation.

Google Play

Google Play requires both a readily discoverable in-app path and a functional external web resource for account and associated-data deletion requests. Legitimate retained data must be disclosed. The public web resource must not require the user to reinstall the app.

Current result

The current Band Licence scaffold is not store-ready for account creation because:

• no technical deletion occurs;
• the external page cannot submit a request;
• provider and backup deletion are not orchestrated;
• final retention disclosures are absent; and
• completion evidence is not generated.

Do not claim store compliance until the exact release and store forms pass an end-to-end test.

21. Required Build and Test Plan

22. Per-request Evidence Template

Case ID:
Request received / channel:
Request type and confirmed scope:
Identity/authority method (do not record secrets):
Schools/accounts/providers in scope:
Incident or legal hold check:
Decision owner and approval:
Data-class decisions and retention authority:
Execution job/version:
Sessions/roles/tokens revoked:
Live records deleted/de-identified/retained:
Providers instructed and confirmed:
Backup treatment and reconciliation record:
Independent verification result:
Requester notified:
Complaint/review information supplied:
Case record disposal date:

Store this evidence under restricted access and the approved case-retention rule. Do not attach the deleted dataset to prove it was deleted.

Authoritative Review Sources

• Queensland OIC — Queensland Privacy Principles
• Queensland OIC — contracting and privacy
• Queensland Government — privacy rights
• Queensland OIC — how to make a privacy complaint
• OAIC — APP 11 security, destruction and de-identification
• OAIC — complain to an organisation or agency first
• Apple — offering account deletion in your app
• Apple — App Review Guidelines
• Google Play — account deletion requirements
• Google Play — User Data policy