Cloud and Hybrid Governance Guide

1. Introduction and Scope

1.0 Normative Language (Mandatory Keywords)

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

• 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 governs the use of public cloud, private cloud, and hybrid arrangements. It covers risk acceptance, shared responsibility model, data residency and cross-border transfer, procurement and contract requirements, and the application of other government IT guides (IAM, Backup, Secrets, etc.) to cloud. It does not mandate or prohibit cloud; it ensures that when cloud is used, it is governed and compliant.

1.2 Scope of Application

This guide applies to all government ministries and departments; state-owned enterprises and parastatals; local government authorities; and government contractors when they use or recommend cloud for government systems or data. It covers IaaS, PaaS, and SaaS where the government is the customer and where government data or processes are involved. It applies to government-owned private cloud and to public or third-party cloud services.

1.3 Definitions and Key Terms

Cloud computing – Delivery of computing resources (e.g. compute, storage, network) as a service over a network; includes public cloud (third-party), private cloud (government or dedicated), and hybrid (combination).

IaaS (Infrastructure as a Service) – Cloud model where the provider supplies virtualised compute, storage, and network; the customer manages OS, applications, and data.

PaaS (Platform as a Service) – Cloud model where the provider supplies a platform (e.g. runtime, database); the customer deploys and manages applications.

SaaS (Software as a Service) – Cloud model where the provider supplies an application; the customer uses the application and is responsible for configuration and data.

Shared responsibility – The division of security and operational responsibilities between the cloud provider (e.g. physical security, hypervisor, managed services) and the government (e.g. identity, access, data encryption, backup, configuration).

Data residency – The geographic or jurisdictional location where data is stored and processed; must meet law and policy (e.g. Data Protection Act, cross-border transfer restrictions).

Cross-border transfer – Transfer of personal data to a jurisdiction outside Malawi; permitted only where the Data Protection Act allows (e.g. adequacy, safeguards).

2. Core Objectives and Success Metrics

2.1 Primary Objectives

Risk-based adoption – Cloud adoption is approved after risk assessment; workload and data classification determine whether cloud (and which cloud model or provider) is permitted.

Shared responsibility – Government and provider responsibilities are documented and contractually reflected; government implements and maintains controls that remain its responsibility (IAM, encryption, backup, config, incident response).

Data residency and transfer – Data residency meets legal and policy requirements (e.g. Data Protection Act, cross-border transfer); no government data in locations that violate law or policy.

Procurement and contract – Cloud procurement and contracts align with Malawi Government Third-Party and Vendor Risk Management Guides; security, compliance, breach notification, and exit are addressed.

Guides application – IAM, Backup, Secrets, Incident Response, and other government guides apply to cloud workloads and data; exceptions are documented and approved.

2.2 Key Performance Indicators (KPIs)

2.3 Minimum Baseline and Prohibitions

• Minimum controls (floor): New cloud adoption SHALL have risk assessment and approval (System Owner + Security Officer). Shared responsibility SHALL be documented per service. Data residency and cross-border transfer SHALL meet Data Protection Act and policy. Government-controlled workloads SHALL apply IAM, Backup, Secrets (and other guides) per respective guides. All exceptions SHALL be in the exception register with compensating controls and expiry.
• Prohibitions: MUST NOT adopt cloud for government data without risk assessment and approval. MUST NOT store or process government data in locations that violate law or policy without Legal exception. MUST NOT grant exception without recording in exception register.

3. Governance and Compliance Framework

3.1 Governance Structure

Document Owner – The Ministry of Information and Communication Technology (MoICT), Department of eGovernment, owns this guide and is responsible for its maintenance, interpretation, and coordination with other government guides (including IAM, Backup, Secrets, and Vendor Risk).

System Owner – Accountable for risk acceptance and compliance for systems in cloud; approves cloud adoption and exception requests within their remit.

Security Officer – Validates that cloud governance and controls meet this guide and governs exceptions.

Procurement or contract owner – Ensures cloud contracts include security, DPA, breach notification, and exit terms per Vendor Risk Guides.

3.2 Risk Assessment and Approval

Before adopting cloud for a workload or data set, a risk assessment is performed: classification of data and system (critical, high, medium, low); suitability of cloud model (public, private, hybrid) and provider; shared responsibility mapping; data residency and transfer implications; and compliance (DPA, e-Transactions, other guides). Approval is by System Owner and Security Officer; critical or high-impact may require senior or MoICT approval. Approval is documented.

Implementation:

(1) Complete risk assessment for each new cloud adoption: data/system classification, cloud model, shared responsibility, data residency, and compliance.

(2) Document shared responsibility per service; ensure government controls (IAM, Backup, Secrets, etc.) are implemented per respective guides.

(3) Obtain System Owner and Security Officer approval; retain assessment and approval for audit.

(4) Review cloud posture at least annually or on material change; update contract and controls as needed.

3.2.1 Minimum Cloud Adoption Approval Pack (Mandatory)

For every new cloud adoption (IaaS, PaaS, SaaS) involving government systems or data, the following artifacts SHALL be produced and retained:

Cloud Adoption Risk Assessment – Completed and signed (System Owner + Security Officer).

Data classification and processing scope – What data, what sensitivity, who are data subjects (if personal data), and intended processing purpose.

Service model and shared responsibility mapping – RACI-style mapping per service (provider vs government vs vendor integrator).

Data residency / cross-border transfer decision – Documented region(s) and transfer safeguards where applicable.

Security baseline confirmation – Evidence that IAM, Secrets, Logging/Evidence, Backup/Recovery (where applicable), and Incident Response requirements will be met.

Contract alignment confirmation – Vendor Risk and procurement checklist (audit rights, breach notification, exit/portability, subprocessors).

Exit and portability plan – Minimum viable exit plan (see Appendix templates) for critical/high-impact services.

• 3.2.2 Cloud Service Model Baselines (IaaS vs PaaS vs SaaS)
• Because controls differ materially by service model, the following SHALL apply as minimum expectations:
• IaaS (government controls OS and above):

Government SHALL apply Server Hardening, Configuration Management, Vulnerability Management, Backup/Recovery, Monitoring, and IAM controls to workloads.

Network segmentation, logging, and key management SHALL be configured by government (or via approved automation).

PaaS (provider controls platform runtime; government controls app/data):

Government SHALL enforce IAM, secrets handling, logging, network controls exposed by the platform, and backup/export capability.

Platform configuration SHALL be treated as configuration under Configuration Management and Change Management.

SaaS (provider controls application; government controls configuration and data):

Government SHALL enforce identity integration (SSO/MFA), access control, logging/audit exports, retention settings, and data export/portability.

Provider breach notification and audit rights SHALL be contractual (Vendor Risk).

3.3 Shared Responsibility

Shared responsibility is documented per service (e.g. provider: physical, network, hypervisor, managed OS; government: identity, access, data encryption, backup, config, app security). Government ensures that its responsibilities are implemented per IAM, Backup, Secrets, Configuration Management, Incident Response, etc. Provider capabilities (e.g. encryption, logging) are used where they meet government requirements; gaps are filled by government or by contract.

• 3.3.1 Shared Responsibility RACI (Mandatory Fields)
• Shared responsibility mapping SHALL include, at minimum:
• Service name and model (IaaS/PaaS/SaaS)
• Control area (Identity, Network, Logging, Backup, Key management, Patch, Incident response, Data deletion)
• Responsible party (Provider / Government / Integrator / Shared)
• Evidence source (what proves the control is implemented)
• Review cadence (at least annually, and on material change)

3.4 Data Residency and Cross-Border Transfer

Data residency is chosen to meet law and policy. Data Protection Act (2024) may restrict cross-border transfer; transfer is only where permitted (e.g. adequacy, safeguards). Cloud provider regions and sub-regions are selected accordingly. Contract and configuration ensure that data is not stored or processed in unauthorised locations.

3.4.1 Residency Enforcement and Verification

Cloud configurations SHALL enforce the approved data region(s) and SHALL prevent unintended replication to unapproved locations where the platform provides such controls.

Evidence of residency configuration (settings, policy, or provider attestation) SHALL be retained with the adoption pack.

Where provider limitations prevent strict enforcement, an exception SHALL be documented with compensating controls (e.g. encryption with government-controlled keys, strict access control, additional monitoring).

3.5 Procurement and Contract

Cloud procurement follows government procurement rules. Contracts align with Malawi Government Third-Party and Vendor Risk Management Guides: security and compliance requirements; audit and evidence rights; breach notification (including to MACRA where personal data); data portability and exit (retrieval or deletion of government data). Contract terms are reviewed by Legal and Security before signature.

3.6 Application of Other Guides

IAM: Identity and access in cloud follow Malawi Government IAM Guides (e.g. federated identity, MFA, least privilege). Backup: Backup and recovery for cloud-hosted data follow Malawi Government Backup and Recovery Guides (RTO/RPO, encryption, retention). Secrets: Secrets used in cloud (e.g. API keys, credentials) are from Malawi Government Secrets Management solution or equivalent. Incident Response: Incidents in cloud are handled per Malawi Government Incident Response Guides; provider incident notification is contractually required. Configuration, Vulnerability, Monitoring: Apply per respective guides. Exceptions (e.g. provider limitation) are documented and compensating controls applied. Related guides: Malawi Government IAM, Backup, Secrets, Incident Response, Vendor Risk, Configuration Management, Vulnerability Management, Monitoring Guides.

3.7 Safe Exception Process

Exceptions to mandatory cloud governance requirements (e.g. provider limitation preventing full control, legacy workload not yet migrated) 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: The System Owner submits an exception request (government form or template), stating the requirement(s) from which an exception is sought, justification, and proposed compensating controls.
• Documentation: Each exception SHALL document: justification; compensating controls and timeline for remediation; risk acceptance by the System Owner and validation by the Security Officer; maximum exception duration (not to exceed 12 months unless re-approved).
• Review: Exceptions SHALL be reviewed at least quarterly; extensions require re-approval.
• Register: All exceptions SHALL be recorded in a cloud exception register and made available for audit.

4. Verification and Evidence Baseline (Audit-Ready Cloud Governance)

To make this guide auditable, ministries SHOULD maintain evidence that demonstrates: risk assessment and approval for each cloud adoption; shared responsibility mapping per service; data residency and contract alignment; guides application (IAM, Backup, Secrets) for government-controlled workloads; exception register. What internal audit checks: Sample of cloud services for risk assessment and shared responsibility; contract and residency. Sampling: Quarterly sample of cloud adoptions; annual contract review. Escalation: Non-compliance → System Owner and Security Officer → remediation plan; repeated → Document Owner and senior management.

4.1 Compliance Reporting

5. Legal Compliance and Training

5.1 Legal and Related Guides

Data Protection Act (2024): data residency, cross-border transfer, security, breach notification. Electronic Transactions and Cybersecurity Act (2016): cybersecurity. Related: IAM, Backup, Secrets, Incident Response, Vendor Risk. Training: System Owners, Security Officers, and procurement on this guide, shared responsibility, and contract requirements.

6. Framework Alignment

This guide contributes to compliance with international frameworks:

• ISO/IEC 27001:2013 – control families A.15, A.14, A.6, A.18
• NIST SP 800-53 Rev. 5 – families SA, PM, CA, PL
• Benchmarks – CIS Cloud Controls

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

7. Appendices

Appendix A: Related Guides

Malawi Government IAM Guides; Malawi Government Backup and Recovery Guides; Malawi Government Secrets Management Guides; Malawi Government Incident Response Guides; Malawi Government Vendor Risk Guides.

Appendix B: Control and Legal Mapping

• Appendix C: Evidence and Artifact Checklist
• Risk assessment: Cloud adoption risk assessment and approval (System Owner, Security Officer); documented shared responsibility per service.
• Contract: Contract aligned with Vendor Risk Guides; data residency and exit terms.
• Guides application: Evidence that IAM, Backup, Secrets, Incident Response, Configuration, Vulnerability, Monitoring guides are applied to cloud workloads.
• Exceptions: Cloud exception register with requirement, justification, compensating controls, risk acceptance, and review/expiry dates.
• Appendix D: Templates (Minimum)

D.1 Cloud Adoption Risk Assessment (Template)

Minimum fields:

• Workload/system name and owner
• Cloud model (public/private/hybrid) and service model (IaaS/PaaS/SaaS)
• Data classification and whether personal data is processed
• Proposed region(s) and residency rationale
• Shared responsibility RACI (link or embedded table)

Required guides mapping (IAM, Secrets, Logging/Evidence, Backup/Recovery, Incident Response, Monitoring, Config, Vulnerability)

• Key risks and mitigations (technical + contractual)
• Decision: approve / approve with conditions / reject
• Sign-off: System Owner, Security Officer, Procurement/Legal as applicable

D.2 Shared Responsibility RACI (Template)

• Control area
• Provider
• Government
• Integrator (if any)
• Evidence
• Review cadence

D.3 Cloud Exit and Portability Plan (Template)

• What data must be exported (datasets, logs, configurations)
• Export formats and tooling
• Time required and dependencies
• Identity transition plan (SSO, user migration)
• Key management and revocation plan
• Data deletion verification and evidence required
• Contractual obligations and vendor support during exit

References

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

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

Malawi Government IAM Guides.

Malawi Government Backup and Recovery Guides.

Malawi Government Secrets Management Guides.

Malawi Government Incident Response Guides.

Malawi Government Vendor Risk Guides.

NIST SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations.

African Union Convention on Cyber Security and Personal Data Protection (AUCC).

SADC Model Law on Data Protection and related frameworks.