Backup and recovery questions for school management, ERP, and SIS

Define what must be recovered

Backup and recovery planning starts with school decisions and critical workflows, not storage volume. Identify student identity, guardian relationships, classes, attendance, assessment, fees, payments, documents, communications, permissions, audit history, configuration, integrations, and support records that the first phase depends on.

For each record, state the recovery priority, acceptable loss, owner, source, dependencies, access, validation, and reconciliation requirement. A backup that restores files but not relationships or permissions may not restore the workflow.

Ask about the recovery path

Ask who detects an outage or corruption, who authorizes recovery, what is restored first, how the school works temporarily, how users are notified, and how changes made during the interruption are reconciled. Test a representative scenario with controlled data.

Include a partial failure, stale copy, incorrect restore, failed integration, changed guardian, payment, assessment, and family-facing record. Record evidence rather than accepting a general statement that backups exist.

• Recovery objectives and critical workflows
• Backup scope, frequency, retention, and encryption
• Restore permissions, relationships, history, and configuration
• Supplier, subprocessor, and support responsibility
• Temporary work, communication, reconciliation, and review

Review suppliers and lifecycle

GOV.UK procurement guidance recommends checking security measures, access control, subprocessors, incident notification, supplier responsibilities, and data return or deletion at contract end. Ask how backups, exports, support copies, and integrations are governed.

The U.S. Department of Education data governance checklist provides prompts on quality, access, security, lifecycle, sharing, disposal, and monitoring. Recovery should preserve the controls that protect data, not only its availability.

Test and document

Run restore exercises at a sensible cadence and document the result, duration, missing data, permissions, downstream outputs, and unresolved action. Name the reviewer and next test date.

A runbook should tell operators what to do during an outage and after service returns. Do not make shared accounts or untracked spreadsheets the recovery plan.

Review after change

Revisit recovery after a new integration, data field, campus, supplier, role model, calendar, or workflow. Review the first 30, 60, and 90 days after launch for incidents, corrections, support, and continuity evidence.

Apply the guidance to one school decision

Before approving this guidance for backup and recovery questions for school management software, translate it into one school-specific decision record. State the workflow, roles, data fields, permissions, evidence, support route, calendar constraint, and condition that would hold the next phase.

Run the decision with controlled data and the people who will operate the workflow. Record what was observed, what remains unknown, who owns the unresolved item, and when it will be reviewed. Revisit the record after launch at 30, 60, and 90 days.

Keep product capability, school responsibility, legal advice, and measured outcome as separate questions. If evidence is incomplete, narrow the claim and the release rather than turning an assumption into a promise.

Ask the accountable owner to confirm the next action in plain language and to identify the people who must be informed. Keep the decision beside the acceptance tests, support guidance, and change record.

Use the same record when the workflow changes. A new integration, campus, role, field, calendar, supplier, or family-facing output can change the risk even when the original screen looks unchanged. Recheck the owner, source of truth, access boundary, retention, support route, and evidence before extending the decision.

Keep the final result readable to operators and reviewers. It should state what is approved, what is deferred, what remains manual, and how a person reports a problem without creating an uncontrolled copy of school data.