Backup Recovery Guide

1. Introduction and Scope

1.0 Normative Language (Mandatory Keywords)

The following keywords are used to express requirement strength in this standard:

• SHALL / MUST: Mandatory requirement. Non-compliance requires an approved exception.
• SHOULD: Recommended requirement. If not implemented, rationale should be documented.
• MAY: Optional requirement.
• MUST NOT / SHALL NOT: Prohibited requirement.

1.1 Purpose

The purpose of this guide is to define how the Government of Malawi backs up and recovers data and systems, plans for business continuity, and tests disaster recovery. It covers the definition of RTO and RPO by system or data criticality, the types and frequency of backups, the protection of backup data (encryption, access control, integrity), retention periods (including alignment with legal and FOI requirements), restore testing, disaster recovery planning and exercises, identification of critical services, alternate sites, and continuity procedures. It is intended to be used alongside the Malawi Government Email Guide (email archiving), the Government Server Security Hardening Guide (encrypted backups), and retention schedules where they exist.

1.2 Scope of Application

This standard applies to all government ministries and departments; state-owned enterprises and parastatals; local government authorities; and government contractors when they are responsible for backing up or recovering government data or systems, or for continuity of government services. It covers data and systems hosted on-premises, in government cloud, or by vendors where the government retains responsibility for backup, recovery, and continuity. It applies to structured data (databases), unstructured data (files, email), and system state (configuration, virtual machines) where backup is feasible and required. It covers critical and high-impact services and the IT and non-IT components needed to recover them.

1.3 Definitions and Key Terms

Backup – A copy of data or system state created for the purpose of restoring after loss, corruption, or disaster; may be full, incremental, or differential, or achieved through continuous replication.

Restore – The process of recovering data or a system from backup to a usable state; restore procedures must be documented and tested.

Recovery Time Objective (RTO) – The maximum acceptable time within which a system or service must be restored after an outage; it drives recovery procedure design and DR capability.

Recovery Point Objective (RPO) – The maximum acceptable amount of data loss measured in time; it drives backup or replication frequency (e.g. hourly backups support up to 1 hour RPO).

Replication – Continuous or near-continuous copying of data to another location or system to support short RPO and failover; used where RPO is very low.

Retention – The period for which backup or archival data is kept; must align with legal, FOI, and operational requirements; personal data subject to Data Protection Act retention and deletion.

Disaster Recovery (DR) – The set of procedures and capability to recover critical systems after a major outage (e.g. site loss, ransomware); includes use of backups, failover, and alternate site.

Business Continuity (BC) – The capability of an organisation to continue delivering critical services during and after a disruption; includes people, process, and technology.

Critical service – A service that must continue or recover quickly for life, safety, law, or essential government function; identified by each ministry with documented dependencies.

Alternate site – A location or capability (e.g. DR site, cloud failover) used to recover operations when the primary site is unavailable.

Runbook – A documented procedure that describes how to recover a service or system (who does what, failover or restore steps, communication).

2. Core Objectives and Success Metrics

2.1 Primary Objectives

Data protection – Critical and high-impact data and systems are backed up according to agreed RTO and RPO; backups are encrypted, integrity-checked, and stored securely.

Recoverability – Restore procedures are documented and tested at least annually for critical systems; DR procedures and exercises validate that recovery can be achieved within RTO.

Retention and compliance – Retention periods align with legal and FOI requirements; personal data in backups is subject to Data Protection Act retention and secure deletion.

Resilience to ransomware – Backups are protected from ransomware (e.g. immutable or air-gapped copy, access control) so that recovery from backup remains possible after a destructive attack.

Consistency – All ministries apply backup and recovery in line with this standard so that government data is protected and recoverable in a secure, auditable manner.

Critical services identified – Each ministry or government entity identifies its critical services and the dependencies (IT, people, facilities, vendors) required to deliver them.

Continuity procedures – Documented procedures (runbooks) describe how to recover each critical service (e.g. failover, restore from backup, alternate site).

Alternate site or capability – Where RTO requires it, alternate site or redundant capability is planned and (where feasible) tested.

Testing – BC/DR plans are tested at least annually (tabletop, exercise, or full DR test); results are documented and used to improve plans.

2.2 Key Performance Indicators (KPIs)

2.3 Minimum Baseline and Prohibitions

• Minimum controls (floor for all ministries):
• RTO/RPO: Critical and high-impact systems SHALL have agreed RTO and RPO documented in a register.
• Backup: Critical systems SHALL have at least daily backup or equivalent (e.g. replication); backups SHALL be encrypted at rest and in transit.
• Restore testing: Critical systems SHALL be restore-tested at least annually; failures remediated within 30 days.
• DR/BC test: Critical services SHALL be included in a DR or continuity exercise at least every 12 months.
• Runbook: Each critical service SHALL have a documented recovery runbook (roles, steps, alternate site, communication).
• Exception register: All exceptions SHALL be recorded with requirement, justification, compensating controls, owner, expiry, review date.
• Prohibitions:

MUST NOT retain backups shorter than legal/FOI requirements without Legal approval.

MUST NOT store backup data unencrypted at rest or in transit without approved exception.

MUST NOT skip restore testing for critical systems without exception and remediation plan.

MUST NOT grant exception without recording in exception register with compensating controls and expiry.

3. Governance and Compliance Framework

3.1 Governance Structure

Document Owner – The Ministry of Information and Communication Technology (MoICT), Department of eGovernment, owns this standard and is responsible for its maintenance, interpretation, and coordination with other government standards (including the Malawi Government Email Standards and Government Server Security Hardening Standards).

System Owner – Accountable for agreeing RTO and RPO for their systems and for participating in restore and DR testing.

Security Officer – Validates that backup and recovery controls meet this standard and governs exceptions.

Backup and recovery operator – Performs backup operations, restore, and DR procedures; maintains backup systems and ensures backups complete and are validated.

Ministry or entity BC/DR lead – Owns the ministry’s BC/DR plan and critical service list; coordinates testing and plan review.

CIRT or crisis team – May coordinate cross-government response during a major incident; works with backup and recovery and Incident Response.

3.2 Compliance Framework

Backup and recovery must align with:

Data Protection Act (2024): Security of processing (backups as processed data); breach notification if backup data is compromised; retention and deletion in line with data minimisation and retention schedules.

Electronic Transactions and Cybersecurity Act (2016): Record-keeping and integrity of electronic records; backups support both.

Freedom of Information Act: Retention of records and ability to retrieve them within the required response period (e.g. 21 days).

Government Server Security Hardening Standards: Encrypted backups; secure handling of backup media and access.

NIST SP 800-53 Rev. 5 (e.g. CP-9, CP-10 for contingency planning and recovery) where systems are categorised under that framework.

3.3 Safe Exception Process

Exceptions to mandatory backup or recovery requirements (e.g. RTO/RPO, encryption, restore testing) SHALL be requested, documented, and reviewed as follows. Exception requests must include: system or data set name; requirement(s) from which exception is sought; justification; compensating controls and timeline; proposed end date; and sign-off from System Owner and Security Officer.

Request via government form or template.

• Documentation: justification; compensating controls and timeline; risk acceptance by System Owner and Security Officer; maximum exception duration (not to exceed 12 months unless re-approved).
• Review: at least quarterly; extensions require re-approval.
• Register: all exceptions SHALL be recorded in an exception register and made available for audit.

3.4 System and Data Categorisation

• Critical: Systems or data essential for life, safety, or core government function. Shortest RTO/RPO (e.g. RTO 4 hours, RPO 1 hour per server hardening DR targets where applicable); most frequent backups; mandatory DR testing.
• High: Important for operations but not immediately life/safety. Moderate RTO/RPO.
• Medium/Low: Longer RTO/RPO and less frequent backup may be acceptable; still must meet retention and restore-test requirements.

3.5 Critical Service Identification

Each ministry or entity identifies critical services (those that must continue or recover quickly for life, safety, law, or essential government function). Dependencies are documented (IT systems, data, people, facilities, vendors). Critical services are prioritised for RTO and for resource allocation during recovery.

3.6 RTO and Recovery Procedures

RTO is set per critical service (e.g. 4 hours for highest criticality per Government Server Security Hardening where applicable). Recovery procedure (runbook) describes: who does what; how to failover or restore (per Backup and Recovery); alternate site or capability; and communication. Procedures are owned and kept current.

Procedure: (1) Document recovery runbook for each critical service: roles, failover/restore steps (per Backup and Recovery), alternate site, and communication.

(2) Assign runbook owner; review and update runbook at least annually or when dependencies change.

(3) Conduct BC/DR test (tabletop, exercise, or full DR) at least annually for critical services; document results and remediate gaps.

(4) Retain test results and plan review evidence for audit.

3.7 Alternate Site and Redundancy

Where RTO requires recovery at an alternate location, an alternate site or cloud/DR capability is identified and contractually or operationally secured. Government Server Security Hardening Guide reference geographic separation and DR site. Redundant systems (e.g. backup email, per Email Standards) are part of continuity. Vendor contracts may include continuity and exit provisions.

3.8 Testing and Review

BC/DR plans are tested: tabletop (discussion-based), exercise (simulated or partial execution), or full DR test. Testing is at least annual for critical services; results are documented; gaps are remediated. Plans are reviewed annually or when services, dependencies, or structure change.

3.9 Safe Exception Process for BC/DR

Exceptions to mandatory BC/DR requirements (e.g. RTO, annual test) SHALL be requested, documented, and reviewed as follows. Exception requests must include: system or service name; requirement(s) from which exception is sought; justification; compensating controls and timeline; proposed end date; and sign-off from System Owner and Security Officer.

Request via government form or template.

• Documentation: justification; compensating controls and timeline; risk acceptance by System Owner and Security Officer; maximum exception duration (not to exceed 12 months unless re-approved).
• Review: at least quarterly; extensions require re-approval.
• Register: all exceptions SHALL be recorded in an exception register and made available for audit.

5. Backup Requirements

5.1 RTO and RPO

Each critical and high-impact system (or data set) must have an agreed RTO and RPO documented with the system owner. RTO and RPO drive backup frequency (e.g. continuous replication or hourly backups for short RPO), restore procedure, and DR design. RTO and RPO are reviewed when business requirements or system criticality change.

Implementation:

(1) For each critical and high-impact system, convene System Owner and IT to agree RTO (maximum acceptable downtime) and RPO (maximum acceptable data loss in time).

(2) Document RTO/RPO in a register or system inventory with review date.

(3) Map backup frequency and type to RPO (e.g. RPO 1 hour implies at least hourly backup or replication).

(4) Map restore and DR procedures to RTO (e.g. RTO 4 hours implies tested restore and, where required, failover within that window).

(5) Re-assess RTO/RPO when systems are upgraded, decommissioned, or when business impact changes.

5.2 Backup Types and Schedule

• Full backup: Complete copy of data or system state; typically scheduled weekly or as the baseline for incremental/differential.
• Incremental or differential: Changes since last full or last backup; reduces storage and time; restore may require multiple steps.
• Continuous replication: For very short RPO (e.g. database replication, storage replication). Choice of type and schedule is determined by RPO, data volume, and operational constraints. Critical systems must have at least daily backup or equivalent (e.g. replication) unless a longer RPO is explicitly approved.

5.3 Encryption and Integrity

Backups must be encrypted at rest (e.g. AES-256 or equivalent). Backup data in transit (e.g. to off-site or cloud) must use TLS 1.2 minimum (TLS 1.3 preferred). Encryption keys must be managed separately from the backup data (per Malawi Government Secrets Management and PKI guide where applicable). Integrity of backups (e.g. checksums, verification after backup) must be checked so that corrupted backups are detected before they are needed for restore.

5.4 Access Control and Location

Access to backup data and backup systems is restricted to authorised personnel. Backup media (tapes, disks, cloud buckets) are access-controlled and logged. Backups are stored in a location or region that meets data residency and security requirements. Off-site or geographically separate copy is required for critical systems to support DR (per Government Server Security Hardening Standards: geographic replication, RTO/RPO).

5.5 Minimum Backup Tier Baseline (Default Targets)

To reduce ambiguity across ministries, the following tier baseline SHOULD be adopted as default targets and adjusted only by documented risk acceptance:

If a system cannot meet the baseline (e.g. technical constraint), an exception SHALL document compensating controls (e.g. additional monitoring, alternate recovery method) and an end date.

6. Retention and Archival

6.1 Retention Periods

Retention periods for backups must align with legal and FOI requirements and with operational need. Routine correspondence and non-record data may have shorter retention (e.g. 3 years per Email Standards where applicable); policy and administrative records longer (e.g. 7 years); legal and contractual longer (e.g. 10 years); historically significant or permanent archive as required. Personal data in backups is subject to Data Protection Act retention and deletion requirements; backups containing personal data must be included in retention and secure deletion procedures. Where backup retention is shorter than record retention, the production or archival copy of the record (not only backup) must satisfy retention.

6.2 Archival

Long-term retention may be satisfied by archival systems (e.g. dedicated archive storage, WORM) rather than by keeping all backups online. The Malawi Government Email Guide describes archival for email; similar principles apply to other data. Archival must be encrypted, access-controlled, and retrievable within FOI and operational timelines.

7. Restore and Disaster Recovery

7.1 Restore Procedures

Restore procedures are documented per system or data set. They include: how to request a restore; which backup to use; steps to perform the restore; validation that the restore succeeded. Restore is performed by authorised personnel; restore actions are logged. Restore testing is performed at least annually for critical systems and for a sample of other systems; results are documented and failures remediated (e.g. fix backup, fix procedure, or re-test within 30 days).

Procedure – restore test:

(1) Select system or data set and backup set (e.g. most recent full + incremental).

(2) Restore to test environment or isolated system; do not overwrite production.

(3) Validate data integrity and application function (e.g. checksum, sample queries, login).

(4) Document result (pass/fail), date, and tester; if fail, open remediation and re-test within 30 days.

(5) Retain test evidence for audit and for annual compliance reporting.

7.2 Disaster Recovery

Critical systems have documented DR procedures that describe how to recover after a major outage (e.g. site loss, ransomware). DR procedures may include: use of backups; failover to alternate site or replica; roles and contact information; sequence of recovery. DR is tested at least every 12 months (tabletop or full exercise); results are documented and used to update procedures and capacity. The Government Server Security Hardening Guide specifies RTO 4 hours and RPO 1 hour for disaster recovery where applicable; this standard applies those targets to backup and recovery design.

7.3 Incident and Ransomware

In the event of ransomware or destructive attack, recovery from backup may be the primary restoration path. Backups must be protected from ransomware (e.g. immutable or air-gapped copy, access control so that compromised production cannot delete backups). Incident response procedures (per Malawi Government Incident Response Guides) must include coordination with backup and recovery teams and with MACRA where personal data is affected.

8. Legal Compliance and Related Standards

8.1 Data Protection Act (2024)

Backups that contain personal data are part of the processing environment; they must be secured (encryption, access control) and included in breach response. If backup data is compromised, breach notification to MACRA and to data subjects may be required per the Act. Retention and deletion of personal data in backups must comply with the Act (e.g. data minimisation, retention limits, secure deletion when retention ends).

8.2 Freedom of Information Act

Government must be able to retrieve records in response to FOI requests within the statutory period (e.g. 21 days). Backup and archival design must support retrieval of records that are no longer in production but are still within retention. Fees and procedures for retrieval follow FOI and policy.

8.3 Related Standards

Malawi Government Email Standards (email archiving, retention). Government Server Security Hardening Standards (encrypted backups, geographic replication, RTO/RPO). Malawi Government Storage Management Standards. Malawi Government Database Management Standards (database backup and restore). Malawi Government Secrets Management Standards (protection of backup encryption keys and access credentials).

9. Training

9.1 Training

Personnel responsible for backup operations, restore, and DR are trained on this standard, on the backup and recovery tools in use, and on restore and DR procedures. System owners are trained on their role (RTO/RPO, participation in testing). Training is refreshed when procedures or technology change.

10. Verification and Evidence Baseline (Audit-Ready Backup and BC/DR)

To make this standard auditable, ministries and backup/BC operators SHOULD maintain evidence that, at minimum, demonstrates:

• RTO/RPO: Register with RTO/RPO per critical/high system; backup schedule and encryption evidence.
• Restore and DR testing: Restore test reports (annual for critical); DR exercise reports; exception register.
• BC/DR plans: Critical service list; recovery runbooks; alternate site or capability; plan review record.
• Exception register: All exceptions with requirement, justification, compensating controls, owner, expiry, review date.
• What internal audit checks: (1) RTO/RPO coverage and backup success; (2) restore test and DR exercise evidence; (3) exception register validity.
• Sampling approach: Quarterly sample of critical systems for backup and test evidence; annual review of BC/DR plans and exception register.
• Escalation path: Non-compliance → System Owner and Security Officer → remediation plan; repeated → Document Owner and senior management.

10.1 Compliance Reporting

11. Framework Alignment

This standard contributes to compliance with international frameworks:

• ISO/IEC 27001:2013 – control families A.12, A.14, A.17
• NIST SP 800-53 Rev. 5 – families CP, MP, PS
• Benchmarks – none specific

Refer to `ISO27001_Mapping.md` and `Multi_Framework_Mapping.md` for the complete mapping tables.

12. Appendices

Appendix A: Related Standards

Malawi Government Email Standards. Government Server Security Hardening Standards. Malawi Government Storage Management Standards. Malawi Government Database Management Standards. Malawi Government Secrets Management Standards. Malawi Government Incident Response Standards. Malawi Government Vendor Risk Standards. Malawi Government Documentation Standards.

Appendix B: Control and Legal Mapping

• Appendix C: Evidence and Artifact Checklist
• RTO/RPO: Documented RTO/RPO per critical/high-impact system; backup schedule and encryption evidence.
• Restore and DR testing: Restore test results (at least annual for critical); DR exercise results; exception register with requirement, justification, and review/expiry dates.
• BC/DR plans: Critical service list; RTO and recovery procedures; alternate site or capability where required.
• Appendix D: Templates (Minimum)

D.1 Restore Test Report (Template)

• System/data set
• Backup set used (date/time; full + incremental/differential as applicable)
• Restore target (isolated environment; not production)
• Steps executed and deviations
• Validation checks performed (integrity + functional)
• Outcome (pass/fail) and issues found
• Corrective actions and due dates
• Evidence links (logs/screenshots/checksums) and sign-off

D.2 DR Exercise After-Action Report (AAR) (Template)

• Exercise scope (systems/services; scenario)
• Roles and participants
• Objectives (mapped to RTO/RPO)
• Timeline and key events
• What worked / what failed
• Gaps and corrective actions (owner + due date)
• Evidence retained location

D.3 Business Impact Analysis (BIA) (Template)

• Service name and owner
• Criticality tier and rationale
• Maximum tolerable downtime
• RTO/RPO targets and dependencies
• Key stakeholders and communications
• Recovery strategy summary

D.4 Critical Service Register (Template)

• Service name, owner, tier
• Dependencies (systems, vendors, facilities, people)
• Recovery procedure/runbook link
• Last test date and outcome

D.5 Exercise Plan and After-Action Report (Templates)

• Scenario, objectives, participants
• Timeline and injects
• Results and corrective actions (owner + due date)

References

Data Protection Act No. 3 of 2024 (Malawi).

Electronic Transactions and Cybersecurity Act (2016) (Malawi).

Freedom of Information Act (Malawi).

Malawi Government Email Standards.

Government Server Security Hardening Standards.

NIST SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations (CP-9, CP-10).

ISO 22301, Business continuity management systems.

NIST SP 800-34, Contingency Planning Guide for Federal Information Systems.