Change Management and Validation 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 governs changes to IT systems, infrastructure, and applications. It covers the lifecycle of a change: request, assessment, approval, scheduling, implementation, validation, and (where necessary) rollback. It applies to all changes that could affect the availability, security, or integrity of government systems, whether the change is manual or automated (e.g. pipeline deployment).

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 perform changes to government systems. It covers changes to servers, network devices, applications, databases, configuration, and cloud resources. It applies regardless of hosting model (on-premises, government cloud, vendor-managed) where the government retains responsibility for the service.

1.3 Definitions and Key Terms

Change – Any modification to infrastructure, applications, configuration, or systems that could affect availability, security, or integrity; may be manual or automated (e.g. pipeline deployment).

Change request – A formal request that describes the change, justification, impact, risk, test plan, rollback plan, and requester; recorded and assessed before approval.

Standard change – A pre-approved, low-risk, repeatable change; logged but not subject to ad hoc approval each time.

Normal change – A change that is assessed, approved, scheduled, implemented, and validated according to the full change process.

Emergency change – A change expedited for critical incident or security fix; implemented with minimal delay; post-implementation approval and review required.

Rollback – The process of reverting a change to restore the previous state when the change fails or causes unacceptable impact; must be documented and tested for non-standard changes.

Change Advisory Board (CAB) – A body that assesses and approves high-risk or critical changes; may include System Owner, Security Officer, and technical leads.

2. Core Objectives and Success Metrics

2.1 Primary Objectives

Controlled change – All changes that could affect availability, security, or integrity are requested, assessed, approved, and validated; unplanned or poorly executed changes are minimised.

Reversibility – Non-standard changes have documented and tested rollback so that recovery is possible when a change fails.

Audit trail – Every change is recorded with request, approval, implementation, and outcome so that compliance and incident analysis are supported.

Risk-based approval – Approval authority is determined by risk and system impact; high-risk changes receive extra scrutiny (e.g. CAB, senior approval).

Integration – Change management aligns with Configuration Management (configuration changes are traceable) and with CI/CD (automated changes governed by approval gates and policy).

2.2 Key Performance Indicators (KPIs)

2.3 Minimum Baseline and Prohibitions

• Minimum controls (floor for all ministries):
• Change record: Every change that could affect availability, security, or integrity SHALL be recorded with request, approval, implementation, and outcome.
• Rollback: Non-standard changes SHALL have documented and (where appropriate) tested rollback before implementation.
• PIR: Failed or rolled-back changes SHALL have a post-implementation review within 5 working days.
• Approval: Approval authority SHALL be determined by risk and system impact; high-risk changes require CAB or senior approval.
• Exception register: All exceptions to the change process SHALL be recorded with requirement, justification, compensating controls, owner, expiry, review date.
• Prohibitions:

MUST NOT implement non-standard changes without documented rollback plan.

MUST NOT skip PIR for failed or rolled-back changes beyond 5 working days without exception.

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 Configuration Management and Government Server Security Hardening Standards).

System Owner – Accountable for risk acceptance for changes to their systems; approves or delegates approval for change requests within their remit.

Security Officer – Validates change process and security impact of changes; approves or advises on changes with security implications; governs exceptions.

Change Manager or implementer – Records change requests, coordinates assessment and approval, schedules implementation, and ensures validation and closure; may chair CAB.

Change Advisory Board (CAB) – Where required, assesses and approves high-risk or critical changes.

3.2 Compliance Framework

Change management supports compliance with:

Electronic Transactions and Cybersecurity Act (2016) (cybersecurity, record-keeping).

NIST SP 800-53 Rev. 5 (e.g. CM-3 change control, CM-4 impact analysis).

Government Server Security Hardening Standards (changes to security config are changes).

Malawi Government Configuration Management Standards (configuration changes are traceable via change request).

3.3 Change Categorisation

Standard change: Pre-approved, low-risk, repeatable; logged but not ad hoc approved. Normal change: Assessed, approved, scheduled, implemented, validated. Emergency change: Expedited for critical incident or security fix; implemented with minimal delay; post-implementation approval and review required. High-risk change: Affects critical service or security; may require Change Advisory Board or senior approval; extra testing and rollback verification.

3.4 Safe Exception Process

Exceptions to mandatory change process (e.g. bypass of approval for defined emergency, deferred documentation) SHALL be requested, documented, and reviewed as follows. Exception requests must include: requirement(s) from which exception is sought; justification; compensating controls; risk acceptance by System Owner (and Security Officer where security impact); proposed end date; and sign-off. Request via government form or template. Documentation: justification; compensating controls; risk acceptance by System Owner (and Security Officer where security impact); 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. Change Lifecycle

4.1 Request

The requester submits a change request that includes: description of the change; justification (business or security need); systems affected; impact and risk; test plan (if applicable); rollback plan; proposed date and duration; and requester identity. The request is recorded in a change management system or register.

Implementation: Ensure the change register or tool captures at minimum: unique ID, title, description, requester, date requested, systems affected, category (standard/normal/emergency), approval status, implementer, scheduled date, actual date, validation outcome, and closure date. Standard changes may reference a pre-approved procedure and log only execution details.

• 4.1.1 Minimum Change Record Fields (Audit Baseline)
• To ensure consistency across ministries, every change record SHALL include, at minimum:
• What: change title and detailed description
• Why: justification (business/security)
• Scope: systems/services affected and impact tier (Critical/High/Medium/Low where used)
• Risk: impact + likelihood assessment and dependencies
• Plan: implementation steps
• Validation: how success will be verified (minimum checks)
• Rollback: rollback steps + trigger criteria (when to rollback)
• Comms: who is notified and when
• Approvals: approver identity and timestamp (or CAB decision reference)
• 4.2.1 Risk Assessment Matrix (Recommended)

Ministries SHOULD adopt a simple risk scoring matrix to route changes to the correct approval path (e.g. delegate vs CAB vs senior approval). At minimum, the matrix should consider:

• Impact (availability, security, citizen service disruption)
• Likelihood of failure
• Blast radius (single system vs cross-ministry/shared platform)
• Reversibility (easy rollback vs complex)

4.2 Assessment and Approval

The change is assessed for impact (availability, security, performance), risk (likelihood and consequence of failure), and dependency on other changes or systems. Approval authority is determined by risk and system impact: low-risk may be approved by System Owner or delegated authority; high-risk may require Change Advisory Board or senior management. Approval is recorded with approver and date. Rejected changes are documented with reason.

4.3 Scheduling

Approved changes are scheduled. Critical or disruptive changes are scheduled in maintenance windows where possible. Conflicting changes (e.g. same system, same time) are resolved. Affected parties (e.g. users, other ministries) are notified of planned downtime or impact.

4.4 Implementation

The change is implemented according to the approved plan. Implementation is performed by authorised personnel (implementer). Deviations from the plan are documented; if deviation introduces significant risk, approval may be re-required. Implementation steps and results are logged.

4.5 Validation and Closure

After implementation, the change is validated: the intended outcome is verified (e.g. service works, config applied, patch installed). If validation fails or the change causes an incident, rollback is executed and the change is closed as failed or rolled back; a post-implementation review is conducted. Successful changes are closed with validation evidence. All closures are recorded.

4.6 Rollback

When a change causes failure or unacceptable risk, rollback is executed according to the documented rollback plan. Rollback is treated as a change (may be emergency); it is logged and validated. Post-incident review identifies root cause and improvement (e.g. better testing, clearer rollback procedure).

5. Documentation and Change Records

This section integrates operational documentation and change record-keeping into the change management framework. Documentation provides a record of system architecture, procedures, and change history; change records create an audit trail of what changed and why.

5.1 Runbooks and Operational Procedures

Critical and high-impact systems have documented runbooks for key procedures: failover, restore, incident response, disaster recovery. Each runbook includes: purpose and when to use; prerequisites (access, tools, approvals); step-by-step procedure; expected outcome; rollback or failure handling; and escalation contacts. Runbooks are tested or walked through at least annually to ensure accuracy. Testing or walk-through is documented with date and outcome. Runbooks are version-controlled or stored in an approved repository (e.g. Confluence, Git) with change history.

Procedure: (1) Identify critical procedures per system; create or update runbook. (2) Assign a document owner (System Owner or delegated procedure owner). (3) Store in version control or approved repository; link to change record when procedure changes. (4) Test or walk-through at least annually; document test date and result. (5) Update when system or procedure changes; track changes in version control.

5.2 Architecture and Design Documentation

Critical and high-impact systems have architecture or design documentation that describes: system context and purpose; major components and relationships; data flows and trust boundaries; dependencies and interfaces; and security and resilience considerations. Architecture documentation is updated when significant architecture changes occur (per Change Management). Documentation supports onboarding, troubleshooting, audit, and continuity.

Minimum arch doc content: System/application name and owner; purpose and users; architecture overview (diagram); major components and dependencies; data flows (where/how data moves); security considerations (auth, access, encryption); operational ownership and runbooks; change history and review cadence.

5.3 Change and Release Records

Every change (standard, normal, or emergency) records what changed, when, and who approved it. For applications and major infrastructure, a change log or release notes are maintained: list of what changed, when, who approved, version or build number (where applicable), and link to change record. Release notes are published to users or operations as appropriate. Change records are retained per government records retention policy and made available for audit and FOI where applicable.

Change record documentation: Each change record includes at minimum: unique ID, title, description (what changed), justification (why), systems affected, category (standard/normal/emergency), approver(s) and approval date, implementer and implementation date, validation outcome, and closure status. Reference to associated runbooks or documentation is noted (e.g. "updated failover runbook per Section 5.1").

5.4 Documentation as Code

Where feasible, runbooks and architecture documentation are stored in version-controlled repositories (e.g. Markdown in Git, AsciiDoc) alongside code. Benefits: change history, review via merge request/pull request, single source of truth. Sensitive content (credentials, internal-only procedures) is not included in public or widely accessible repositories; access control is applied. Documentation as code is encouraged for systems where code and operations are tightly coupled (e.g. infrastructure-as-code, containerized applications).

5.5 Document Ownership and Retention

100% of operational documentation has an assigned owner (System Owner or process owner). Owners are responsible for reviewing and updating documentation at least annually or when the system or process changes. Documentation that is part of government records (e.g. change logs, incident reports, architecture docs supporting audit) is retained per government records retention schedule and Freedom of Information requirements. Documentation accessibility is managed: operational runbooks are accessible to those who need them for their role; sensitive or internal-only documentation has restricted access.

6. Emergency and Standard Changes

5.1 Emergency Changes

Emergency changes are those required to restore service or to mitigate a critical security vulnerability where delay would cause significant harm. They follow an expedited process: minimal documentation at time of implementation, implementation by authorised personnel, and mandatory post-implementation approval and review within a defined period (e.g. 72 hours). The emergency and its justification are documented as soon as practicable. Overuse of emergency classification is reviewed and addressed (e.g. more capacity for normal change, or better planning).

5.2 Standard Changes

Standard changes are pre-approved, low-risk, and repeatable (e.g. defined OS patch, defined application update). They are documented in a standard change library with procedure, rollback, and approval (one-time for the procedure). Each execution is logged (what, when, who, outcome). Standard changes are reviewed periodically to ensure they remain low-risk.

6. Integration with CI/CD and Configuration Management

6.1 Automated Deployments

Where changes are implemented via CI/CD pipelines (e.g. application deployment, config push), the pipeline is governed by this standard: deployments are traceable (e.g. to a change request or release record), approval gates may be required for production, and rollback (e.g. redeploy previous version) is defined and tested. The Malawi Government CI/CD Standards define pipeline design; this standard defines the change control that wraps it.

6.2 Configuration Changes

Changes to configuration (per Malawi Government Configuration Management Standards) are changes under this standard. Baseline updates, drift remediation, and config deployments follow the same request-approve-implement-validate cycle where they affect production or security.

7. Legal Compliance and Audit

7.1 Electronic Transactions and Cybersecurity Act (2016)

The Act requires appropriate cybersecurity measures and record-keeping. Change management provides a record of what was changed and when, supporting audit and investigation.

7.2 Audit

Auditors must be able to verify that changes are requested, approved, implemented, and validated in line with this standard. Change records, approval logs, and validation evidence are retained per government records policy and are available for audit.

8. Training

8.1 Training

Requesters, approvers, implementers, and validators are trained on this standard and on the change management process and tools used by their ministry or centrally. Training includes when to use standard vs normal vs emergency, how to document rollback, and how to conduct post-implementation review.

9. Verification and Evidence Baseline (Audit-Ready Change Management)

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

• Change records: Request, approval, implementation, validation, and closure for all changes; emergency change PIR.
• Rollback: Rollback plans and (where required) test evidence for non-standard changes.
• Exception register: All exceptions with requirement, justification, compensating controls, owner, expiry, review date.
• What internal audit checks: (1) Sample of changes for full record; (2) rollback and PIR for failed changes; (3) exception register validity.
• Sampling approach: Quarterly sample of changes; annual review of exception register.
• Escalation path: Non-compliance → System Owner and Security Officer → remediation plan; repeated → Document Owner and senior management.

9.1 Compliance Reporting

10. Framework Alignment

This standard contributes to compliance with international frameworks:

• ISO/IEC 27001:2013 – control families A.12, A.14, A.9
• NIST SP 800-53 Rev. 5 – families CM, PL, SA
• Benchmarks – none specific

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

11. Appendices

Appendix A: Related Standards

Malawi Government Configuration Management Standards. Malawi Government CI/CD Standards. Government Server Security Hardening Standards. Malawi Government Incident Response Standards.

Appendix B: Control and Legal Mapping

• Appendix C: Evidence and Artifact Checklist
• Change records: Change request, approval, implementation, and validation evidence; emergency change post-implementation review.
• Exception register: Requirement, justification, compensating controls, risk acceptance, and review/expiry dates.
• Appendix D: Templates (Minimum)

D.1 Change Request (Template)

• Title, description, systems affected
• Category (standard/normal/emergency)
• Justification
• Risk assessment summary and dependencies
• Implementation plan (steps)
• Validation plan (checks)
• Rollback plan (steps + triggers)
• Communications plan
• Approvals (who/when)

D.2 Standard Change Library Entry (Template)

• Standard change name and scope
• Preconditions and eligibility (why it’s low-risk)
• Exact steps (runbook)
• Validation checks
• Rollback steps
• Evidence to retain per execution
• Review cadence (e.g. annual) and owner

D.3 Post-Implementation Review (PIR) (Template)

• Summary of change and outcome
• What went well / what went wrong
• Incidents or rollbacks triggered (if any)
• Root cause (if failure)
• Corrective actions (owner + due date)

References

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

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

Government Server Security Hardening Standards.

Malawi Government Configuration Management Standards.

Malawi Government CI/CD Standards.