Storage Management 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 standard is to define how the Government of Malawi designs, operates, and secures storage used for government data. It covers storage tiers and lifecycle, encryption and access control, cost and performance optimisation, and prevention of misconfiguration. It applies to block, file, and object storage whether on-premises, in government cloud, or in vendor-managed environments where the government retains responsibility.

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 operate or manage storage for government data. It covers primary storage, backup storage, and archival storage used for government systems and data.

1.3 Definitions and Key Terms

Storage – Systems and media used to store government data: block storage, file storage, object storage; includes primary, backup, and archival storage.

Storage tier – A category of storage by access pattern and cost: hot (frequently accessed, higher performance/cost), cool (less frequent, lower cost), archive (long-term retention, lowest cost).

Lifecycle policy – Rules that define how data moves between tiers (e.g. from hot to cool after 90 days) or is deleted after retention; supports cost and compliance.

Encryption at rest – Protection of stored data using encryption (e.g. AES-256) so that data is unreadable without the key; keys managed via HSM, KMS, or governed secrets solution.

Access control – Restriction of who can read, write, delete, or administer storage; aligned with IAM; default deny; public or anonymous access prohibited unless justified and approved.

Misconfiguration – Incorrect storage setup that creates risk (e.g. public bucket, weak ACL, over-permissive policy); must be detected and remediated within defined SLA.

Retention – The period for which data is kept; must align with records schedules, Data Protection Act, and FOI; secure deletion when retention ends.

2. Core Objectives and Success Metrics

2.1 Primary Objectives

Security – All storage holding sensitive or personal data is encrypted at rest; access is restricted by identity and role; no unintended public or excessive access.

Lifecycle and retention – Lifecycle policies are defined for classified storage; retention aligns with legal and FOI requirements; secure deletion when retention ends.

Cost and efficiency – Storage is tiered and right-sized; unused or orphaned storage is reclaimed; cost is optimised without compromising security or compliance.

Misconfiguration prevention – New storage follows checklists (encryption, access, no public); automated or periodic checks detect public buckets, weak ACLs, or over-permissive policies; critical misconfigurations remediated within 5 days.

Consistency – Storage management aligns with Backup and Recovery, Database Management, and Email Standards so that government data is protected and retained consistently.

2.2 Key Performance Indicators (KPIs)

2.3 Minimum Baseline and Prohibitions

• Minimum controls (floor for all ministries):
• Encryption: All storage holding sensitive or personal data SHALL be encrypted at rest (e.g. AES-256); keys managed via HSM, KMS, or governed secrets solution.
• Access control: Default deny; access restricted by identity and role (IAM); no public or anonymous access unless explicitly justified and approved in exception register.
• Lifecycle: Classified storage SHALL have a defined lifecycle (tier, retention, secure deletion) documented in a schedule; secure deletion when retention ends per DPA/FOI.
• Misconfiguration: New storage SHALL pass a provisioning checklist (encryption, access, no public); automated or periodic scans for public buckets and over-permissive policies; critical findings remediated within 5 days.
• Exception register: All exceptions SHALL be recorded (system, requirement, justification, owner, expiry, review) and made available for audit.

Tiering:

• Tier
• Encryption
• Access
• Lifecycle
• Misconfiguration SLA
• Critical/High
• Mandatory at rest
• IAM only; no public
• Mandatory lifecycle and retention
• 24–48 hours for critical
• Medium
• Mandatory at rest
• IAM; no public
• Lifecycle within 18 months
• 5 days
• Low
• Mandatory for sensitive/personal data
• IAM; no public
• Per schedule
• 5 days
• Prohibitions:

MUST NOT create storage with public or anonymous access unless approved via exception with compensating controls and expiry.

MUST NOT store sensitive or personal data in unencrypted storage.

MUST NOT retain data beyond documented retention period without legal hold or exception.

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

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 Backup and Recovery, Secrets Management, and IAM).

System Owner – Accountable for storage holding their data; ensures encryption, access control, and lifecycle meet this standard; approves exceptions within their remit.

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

Storage or infrastructure administrator – Implements storage tiers, lifecycle policies, encryption, and access control; performs misconfiguration checks and remediation.

3.2 System Categorisation

Storage holding High Impact (classified or highly sensitive) data requires strictest encryption, access control, and lifecycle; misconfiguration remediation within shortest SLA. Medium and Low Impact storage still require encryption at rest and access control per this standard; lifecycle and retention align with records schedules and Data Protection Act.

3.3 Storage Tiers and Lifecycle

Hot: Frequently accessed; higher performance and cost; for active workloads. Cool: Less frequent access; lower cost; for backup and near-line. Archive: Long-term retention; lowest cost; for compliance and FOI. Lifecycle policies move data between tiers or delete after retention. Retention periods align with records schedules and Data Protection Act; secure deletion when retention ends (per Backup and Recovery and DPA).

3.4 Encryption and Access Control

All storage holding sensitive or personal data must be encrypted at rest (e.g. AES-256). Keys are managed via HSM, KMS, or governed secrets solution. Access to storage (read, write, delete, administer) is restricted by identity and role (IAM); default is deny. Access is logged and reviewed. Public access or anonymous access is prohibited unless explicitly justified and approved. Storage in cloud or shared environments must have access controls that prevent cross-tenant or unintended exposure; configuration is reviewed and tested.

• 3.4.1 Runbook: New Storage Provisioning
• Element
• Content
• Trigger

New storage (bucket, volume, share) is to be created for government data.

Prerequisites

Data classification; retention requirement; provisioning checklist (Appendix D.1); access to storage platform and IAM.

Steps

1. Confirm storage type (object/file/block) and purpose; record data classification and retention. 2. Enable encryption at rest; note key management (KMS/HSM). 3. Configure access control: IAM roles/groups only; default deny; no public or anonymous. 4. Enable logging and set retention location for access logs. 5. Configure lifecycle policy (tiering/deletion) where applicable per retention. 6. Complete checklist; obtain System Owner sign-off if High/Critical. 7. Register in storage inventory.

Validation

Checklist complete; encryption on; no public access; lifecycle set; inventory updated.

Rollback / failure

If created without checklist: apply controls immediately; document deviation; scan to verify.

Evidence

Completed provisioning checklist; inventory entry; config snapshot.

• 3.4.2 Runbook: Misconfiguration Scan and Remediation
• Element
• Content
• Trigger

Scheduled (e.g. weekly) or on-demand; after any bulk storage change.

Prerequisites

Automated or manual scan tool; access to storage configs; remediation authority; ticketing or change process.

Steps

1. Run scan for public buckets, anonymous access, over-permissive ACLs, unencrypted sensitive data. 2. Triage: Critical (public/exposed) → 5 days; High → 15 days; Medium → 30 days. 3. For each finding: create remediation task; link to Change Management if change required. 4. Critical: contain immediately (remove public); then full remediation. 5. Verify with re-scan; close task with evidence. 6. Retain scan results and remediation evidence for at least 12 months.

Validation

Scan completed; critical remediated within 5 days; evidence retained.

Rollback / failure

If remediation breaks access: revert per change process; document; re-remediate with test.

Evidence

Scan report; remediation tickets; re-scan proof; exception register entry if delayed.

• 3.4.3 Runbook: Public Exposure Response
• Element
• Content
• Trigger

Storage is detected as publicly accessible or over-permissive (scan, alert, or report).

Prerequisites

Access to storage config; Security Officer contact; incident process if sensitive/personal data exposed.

Steps

1. Contain: Remove public access immediately (or restrict to minimum); preserve configuration and log evidence before change. 2. Assess: Identify data exposed, classification, time window, and access logs; determine if breach. 3. Escalate: Notify Security Officer; if sensitive/personal data exposed, trigger Incident Response (MACRA/DPA if breach). 4. Remediate: Correct policies and ACLs; implement preventive controls (guardrails, scanning); review all access grants. 5. Evidence: Retain incident record, config snapshot, logs, and remediation proof for audit.

Validation

Public access removed; impact assessed; incident raised if required; remediation and evidence complete.

Rollback / failure

If business need required temporary re-open: document as exception; time-bound; compensating controls.

Evidence

Incident record; config before/after; access logs; remediation proof; exception if applicable.

3.5 Cost and Misconfiguration Prevention

Cost is optimised through tiering, lifecycle, and right-sizing. Unused or orphaned storage is identified and reclaimed. Misconfiguration prevention: checklists for new storage (encryption, access, no public); automated or periodic checks for public buckets, weak ACLs, or over-permissive policies; remediation within defined SLA.

3.6 Safe Exception Process

Exceptions to mandatory storage requirements (e.g. encryption at rest, access control) 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.

4. Verification and Evidence Baseline (Audit-Ready Storage)

To make this standard auditable, ministries and storage administrators SHOULD maintain evidence that, at minimum, demonstrates:

• Encryption and access: Storage inventory with encryption status for sensitive/personal data; access control config (no public); annual access review records.
• Lifecycle: Lifecycle policies and retention schedule; secure disposal evidence (method, date, sign-off) when data is deleted.
• Misconfiguration: Scan results and remediation evidence (critical within 5 days); provisioning checklists for new storage.
• Exception register: All exceptions with requirement, justification, compensating controls, owner, expiry, review date.
• What internal audit checks: (1) Sample of storage for encryption and access config; (2) lifecycle coverage and disposal evidence; (3) scan and remediation timeliness; (4) exception register validity.
• Sampling approach: Quarterly sample of storage assets (e.g. 5–10% of buckets/volumes); annual full review of lifecycle and exception register.
• Escalation path: Non-compliance → System Owner and Security Officer → remediation plan; repeated or material → Document Owner and senior management.

4.1 Compliance Reporting

5. Legal Compliance and Training

5.1 Legal and Related Standards

Data Protection Act (2024): security of processing, retention, secure deletion; lawful basis for personal data in storage.

FOI: retrievability of government records within statutory period where storage holds records.

Electronic Transactions and Cybersecurity Act (2016): record-keeping and integrity.

• Related standards: Malawi Government Backup and Recovery Guide (`backup-recovery/backup-recovery-guide.md`); Malawi Government Secrets Management Guide (`secrets-management/secrets-management-guide.md`); Malawi Government IAM Guide (`iam/iam-guide.md`); Government Server Security Hardening Guide (`server-hardening/server-hardening-guide.md`).
• Training: Storage and security staff on this standard, encryption, access control, lifecycle, and runbooks; at role assumption and refreshed at least annually.

6. Framework Alignment

This standard contributes to compliance with international frameworks:

• ISO/IEC 27001:2013 – control families A.8, A.12, A.10, A.9
• NIST SP 800-53 Rev. 5 – families MP, SC, AC
• Benchmarks – CIS Storage Benchmarks

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

7. Appendices

Appendix A: Related Standards

Malawi Government Backup and Recovery Guide; Malawi Government Secrets Management Guide; Malawi Government IAM Guide; Government Server Security Hardening Guide.

Appendix B: Control and Legal Mapping

• Appendix C: Evidence and Artifact Checklist
• Storage inventory: Evidence of encryption and access control for sensitive/personal data; lifecycle and reclamation.
• Misconfiguration: Scan or checklist results; remediation within SLA; exception register with requirement, justification, and review/expiry dates.
• Access review: Evidence of annual access and permission review; removal of unused access; key/lifecycle management where applicable.
• Appendix D: Templates (Minimum)

The following templates SHOULD be used as standard formats: New Storage Provisioning Checklist (D.1); Lifecycle Policy (D.2); Exception request content (Section 3.6).

D.1 New Storage Provisioning Checklist (Template)

• Item
• Confirmation
• Storage type (object/file/block) and purpose
• Data classification and retention requirement
• Encryption at rest enabled (key management noted)
• Access control model (roles/groups); default deny
• Public access disabled
• Logging enabled and retention location
• Lifecycle policy configured (tiering/deletion) where applicable
• System Owner sign-off (High/Critical)

D.2 Lifecycle Policy Example (Template)

• Move data from Hot → Cool after ___ days
• Move data from Cool → Archive after ___ days
• Delete (or transition to permanent archive) after retention period ___
• Exceptions and legal hold handling

References

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

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

NIST SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations (SC-28, AC-3).

CIS Benchmarks (where applicable).