Secure Delivery 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

This consolidated standard defines how the Government of Malawi designs, operates, and governs the end-to-end delivery of software and infrastructure. It covers:

Automation and configuration code (Infrastructure as Code, scripts, pipeline definitions) – version-controlled, reviewed, and deployed in governed fashion.

Build and deployment pipelines (CI/CD) – automated stages designed to prevent risky changes and enforce security scanning, approval gates, and rollback capability.

Configuration management – baseline configurations defined, version-controlled, applied consistently, and monitored for drift.

Supply chain security – dependencies and third-party components from approved sources, scanned for vulnerabilities, with Software Bills of Materials (SBOM) to support incident response.

These four disciplines are interdependent: pipelines execute automation, automation applies configuration, configuration depends on vetted dependencies, and scanning of all three (code, configuration, dependencies) prevents vulnerable or malicious changes from reaching production.

1.2 Scope of Application

This standard applies to:

• All government ministries, departments, state-owned enterprises, parastatals, and local government authorities
• Government contractors and consultants who develop or operate software and infrastructure on behalf of government
• All code, configuration, infrastructure, and dependencies that affect government systems or data
• On-premises, government cloud, and vendor-managed environments where the government retains responsibility

1.3 Definitions and Key Terms

2. Core Objectives and Success Metrics

2.1 Primary Objectives

The unified delivery standard achieves five primary objectives:

Secure pipelines and automation – Code, configuration, and infrastructure automation are stored in version control; pipelines obtain secrets from the Secrets Management solution (never embed); no secrets in repositories or logs; execution is auditable.

Governed code and configuration – All changes to code and automation are reviewed and approved before production; production deployments link to change records per Change Management; configuration is maintained as code and version-controlled.

Scanned artifacts and dependencies – Every artifact (code build, container, configuration) is scanned for vulnerabilities, secrets, and misconfigurations before production; critical/high findings are remediated or accepted with documented exceptions; dependencies are from approved sources where policy applies.

Baseline enforcement and drift detection – Systems are brought into compliance with defined baselines (aligned with Server Hardening and CIS Benchmarks); configuration is compared to baseline regularly; unauthorized drift is remediated within defined timelines; all configuration changes are traceable to change records.

Reversibility and traceability – Every production deployment and change is linked to an artifact version, a source commit, and a change record; rollback procedures are tested; incidents and compliance investigations can identify exactly what was deployed.

2.2 Key Performance Indicators (KPIs)

2.3 Minimum Baseline and Prohibitions

Minimum controls (floor): No secrets in code or config; secrets from Secrets Management solution. All production-affecting code changes reviewed before merge. All production artifacts scanned (secrets, vulnerabilities, misconfigurations); critical/high remediated or excepted. In-scope systems have defined baseline; drift detected and remediated per SLA. Production deployments linked to change record and artifact version. Critical systems have tested rollback procedure. All exceptions in exception register with compensating controls and expiry. Prohibitions: MUST NOT deploy to production without change record and artifact traceability. MUST NOT embed secrets in code, config, or pipeline. MUST NOT promote artifacts with unresolved critical/high findings without approved exception. MUST NOT grant exception without recording in exception register.

3. Governance and Compliance Framework

3.1 Governance Structure

• Role
• Responsibilities
• Document Owner

MoICT Department of eGovernment; maintains this standard and coordinates with Change Management, IAM, Secrets Management, Server Hardening, and Vulnerability Management.

System Owner

Accountable for systems delivered via this standard; approves baseline exceptions and production deployments; owns rollback decisions.

Security Officer

Validates pipeline security, scanning results, baseline compliance, and exceptions; approves security-related exceptions.

Pipeline/Platform Owner

Designs and operates CI/CD pipelines and platform; configures approval gates, scanning, secrets integration, and monitoring; supports audit and incident response.

Developer/automation owner

Uses version control and pipelines per this standard; does not embed secrets; checks in code/configuration; links production deployments to change records.

3.2 Compliance Framework

Secure delivery aligns with:

Malawi Government Change Management Standards – All production deployments and infrastructure changes follow approval and tracking processes.

Malawi Government Secrets Management Standards – Pipelines and automation never embed secrets; runtime retrieval from Secrets Management solution is mandatory.

Malawi Government Server Security Hardening Standards – Configuration baselines align with CIS Benchmarks Level 1 and NIST SP 800-53.

Malawi Government Vulnerability Management Standards – Vulnerabilities in code and dependencies follow remediation timelines.

Malawi Government IAM Standards – Pipeline execution and approvals follow identity and access control requirements.

Data Protection Act (2024) – Security of processing applies to code and configuration that handle personal data.

Electronic Transactions and Cybersecurity Act (2016) – Cybersecurity controls and record-keeping apply to delivery processes.

4. Code and Automation Management

4.1 Version Control and Code Review

Principle: All code, automation (IaC, scripts, pipeline definitions), and configuration is stored in version-controlled repositories with access control, audit trail, and branch protection.

4.1.1 Repository Requirements

• Repositories: All production-affecting code, automation, and configuration is in governed repositories within 12 months.
• Branching: Branching strategy is defined (e.g. main, develop, feature); direct push to production/main is restricted.
• Merge/pull request: All changes require a pull or merge request before merge to main/production.
• History: Commit history is preserved; force-push that rewrites history is restricted or prohibited for production branches.

4.1.2 Code Review Process

Requirement: All changes to production-affecting code and automation are reviewed by at least one other person before merge.

Review checklist:

• Logic and correctness per design
• Security (no secrets, no unsafe patterns, no hardcoded credentials)
• Alignment with infrastructure or configuration baselines
• Pre-merge secret scanning passes (no findings or findings remediated)
• Approval is documented

Implementation: (1) Require minimum 1 approver on pull request; configure in repository settings. (2) Run pre-merge secret scan (GitHub Advanced Security, Gitguardian, or equivalent); block merge if secrets detected. (3) Integration: Link pull request to change record or standard-change ID where production deployment is expected. (4) Retain review and approval evidence for audit.

5. CI/CD Pipeline and Secure Deployment

5.1 Secure Pipeline Baseline

Principle: Pipelines are designed to prevent risky changes, enforce security controls, and ensure every production artifact is approved, scanned, and traceable.

5.1.1 Mandatory Baseline Requirements

All production pipelines define and implement the following:

Pipeline as code – Pipeline definition is version-controlled; direct UI edits that bypass version control are not the sole source of truth.

Build once, promote same artifact – Production deployment uses the same artifact built in CI (by immutable identifier: digest, checksum, or version), never a rebuild in production.

Artifact immutability – Production artifact references use immutable identifiers (e.g. container image digest-pinned, not floating tags like "latest").

Secrets handling – Secrets are obtained from the Malawi Government Secrets Management solution at runtime; secrets MAY NOT be stored in pipeline definitions, environment files, code, or logs.

Scanning gates – Artifacts are scanned before production promotion:

• Secrets scanning – Detect secrets in code and artifacts
• Dependency (SCA) scanning – Detect vulnerable dependencies
• Container image scanning (where containers used) – Scan base images and final images
• IaC/configuration scanning (where automation used) – Detect misconfigurations

Critical/high findings block promotion unless an exception is documented and approved.

Restricted production deploy – Production deployments are executable only by:

• Approved pipelines (configured in CI/CD system)
• Approved identities (restricted service account with audit logging)
• Change Management approval gate (manual approval or standard-change reference)
• Approval gate + change linkage – Production deploy stage requires or captures:
• Change request ID (normal change, standard change standard-change ID, or emergency change with fast-track approval)
• Approver identity and timestamp
• Artifact version and source commit
• Logging and audit – Every production deployment produces an audit record:
• System/service name
• Environment and artifact identifier (immutable)
• Source commit and pipeline run ID
• Requester and approver identities
• Change record reference
• Time, result, and validation evidence

Environment separation – Credentials and permissions for dev/test vs. production are strictly separated; compromise of dev/test MUST NOT grant production deploy access.

• Runner/agent security – Pipeline execution environments (runners, agents, build boxes) are:
• Minimal and hardened per Server Hardening Standards
• Patched per Vulnerability Management timelines
• Audited for unauthorized access
• Isolated from production (network, identity, filesystem)
• Rollback capability – A defined rollback mechanism exists:
• Redeploy previous artifact, revert configuration, or restore from backup
• Rollback tested at least annually for critical systems
• Rollback evidence documented (participants, steps, outcome)

6. Configuration Management and Baselines

6.1 Baseline Definition and Maintenance

Principle: System configuration is defined in version-controlled baselines aligned with security standards; all in-scope systems conform to baselines or have approved exceptions.

6.1.1 Baseline Requirements

Baseline per system type – Each system type and role (e.g. Linux web server, Windows domain controller, database server) has a defined baseline.

Baseline content – Each baseline specifies:

• System type and role
• Required configuration settings (explicit values where feasible)
• References to control sources (CIS Benchmark sections, Server Hardening sections)
• Validation method (how compliance is checked; tools/commands or scanner outputs)

Version control – Baselines are stored in version control or configuration store; all changes require change request and approval; version history is retained.

Review cadence – Baselines are reviewed and updated at least annually; reviews are documented.

6.1.2 Baseline Application

New systems – Built to applicable baseline before entering service.

Existing systems – Brought into compliance with baselines per prioritized plan (High Impact systems first); compliance achieved within 24 months.

Configuration deployment – Configuration applied via automation (e.g. Ansible, Terraform) where possible; manual application tracked and audited.

6.2 Configuration Storage and Version Control

Requirement: Configuration that can be expressed in code (IaC, config files) is stored in version-controlled repositories with access control and audit trail.

6.2.1 Storage and Integration

IaC repositories – Infrastructure as Code (Terraform, Ansible, etc.) stored in version control; changes follow pull request process.

Configuration store – System-generated or managed configurations (application settings, deployment parameters) stored in a configuration management database (CMDB) or equivalent.

Secrets separation – Repositories do NOT contain secrets; automation retrieves secrets from Secrets Management solution at runtime per 4.3 below.

State management – For automation that uses state (e.g. IaC state files):

• State storage is access-controlled and logged
• State backups exist for critical automation
• State MUST NOT contain unprotected secrets

6.3 Drift Detection and Remediation

Principle: Configuration is compared to baseline at defined intervals; unauthorized drift is remediated within defined SLAs.

6.3.1 Drift Procedure

Detection – Configuration of in-scope systems is scanned against baseline or version-controlled source at defined cadence:

• High Impact: daily or real-time
• Medium Impact: weekly
• Low Impact: monthly
• Classification – Drift is classified as:
• Authorized (linked to a change record or approved exception)
• Unauthorized (no change record; requires remediation)
• Remediation – Unauthorized drift is:
• Contained: reverted to baseline where safe
• Investigated: cause determined; potentially a security incident if malicious
• Documented: recorded in incident or change systems with timeline and evidence
• Validated: configuration verified to conform to baseline
• Timelines:
• Critical drift: remediated within 5 working days
• Security-relevant drift: remediated within 10 working days
• Other drift: remediated within 30 days

CMDB synchronization – After remediation, CMDB mapping is updated to reflect which baseline version is in place.

7. Software Supply Chain Security

7.1 Approved Sources and Dependency Management

Principle: Software components come from approved or vetted sources; dependencies are tracked, scanned, and kept current.

7.1.1 Approved Source Policy

Policy definition – For production workloads, ministries and development teams define and enforce an approved-source policy covering:

• Package registries/repositories: which registries are approved (official mirrors, internal mirrors, vendor repos)
• Container registries and base images: which registries and base image families are allowed (e.g. Docker Hub official, Red Hat, Alpine, government-approved mirrors)
• Integrity mechanisms: what integrity signals are required where supported (signatures, checksums, provenance)
• Exception handling: how to request temporary use of non-approved source with compensating controls
• Maintenance: Approved source policy is reviewed and updated at least annually; changes require approval.

7.1.2 Dependency Pinning

Version pinning – Production builds pin dependency versions (lockfiles, version constraints) to support reproducibility and audit.

Reproducibility – Build systems produce metadata to reproduce "what was built" for a release: source commit + dependency set/SBOM.

Dependency updates – Automated updates (if used) require review and testing before promotion to production; updates follow Change Management approval.

7.2 SBOM and Dependency Inventory

Requirement: Critical and high-impact applications maintain SBOM or dependency inventory; SBOM is used for vulnerability management and incident response.

• 7.2.1 SBOM Content and Storage
• For critical and high-impact systems, SBOM includes, at minimum:
• Component name and version
• Source (registry/repo/vendor)
• License identifier where available
• Direct vs. transitive dependency (if tooling supports)
• Build/release identifier (artifact digest/version) and source commit reference
• Generation date and tool used

SBOM is stored with release records or in a designated SBOM repository; it is retrievable for audit and incident response.

7.3 Vulnerability Scanning and Remediation

Principle: Dependencies are scanned for known vulnerabilities in CI/CD pipelines and ongoing per Vulnerability Management.

7.3.1 Scanning in Pipelines

Scanning gates – Pipelines scan dependencies and container base images for known vulnerabilities; results are logged and available to Security Officer.

• Remediation – Critical and high vulnerabilities are remediated per Vulnerability Management timelines:
• Update dependency
• Apply patch
• Accept exception with compensating controls (documented and approved)

Blocking or flagging – Critical/high findings flag or block promotion to production unless exception is approved and documented.

7.3.2 Supply Chain Incident Response

When a major dependency vulnerability or supply chain compromise is disclosed (e.g. widely exploited library, malicious package):

Identification – Security Officer initiates identification of affected systems using SBOM/inventory.

Assessment – System Owners assess their systems for exposure.

Remediation – Systems are remediated per Vulnerability Management and Incident Response timelines (upgrade, patch, disable, compensate).

Evidence – Assessment and actions retained for audit.

8. Infrastructure Automation

8.1 Infrastructure as Code (IaC) Execution Model

Principle: Infrastructure changes are defined as code, reviewed, and applied through approved pipelines and identities.

• 8.1.1 Production Automation Requirements
• For automation that changes production infrastructure:
• Apply/execute permissions – Apply or execute operations are restricted to:
• Approved identities (service accounts with audit logging)
• Approved execution environments (CI/CD pipelines, designated management systems)
• Change Management approval where required per section 5.1.7

Plan/preview – Before applying changes, a plan or preview output is produced and reviewed (where tooling supports); plan is linked to change record.

State and inventory handling:

• State storage (e.g. Terraform state) is access-controlled and logged
• State backups exist for critical automation workflows
• State MUST NOT contain unprotected secrets
• Production run record – Each production automation run is recorded with:
• Automation repo, version/tag, source commit
• Execution environment and operator identity
• Change record ID and approvals
• Plan/preview reference
• Outcome and validation evidence
• Rollback performed (yes/no) and evidence

9. Exception Management and Rollback

9.1 Exception Process

Principle: Exceptions to mandatory requirements are documented, time-limited, and reviewed regularly.

• 9.1.1 Exception Request Process
• Exception requests must include:
• Requirement(s) from which exception is sought
• Justification (technical constraint, business priority, timeline)
• Compensating controls (specific, measurable)
• Proposed end date and remediation plan milestones
• Sign-off from System Owner and Security Officer
• Procedure:
• Submit via government form or template
• Security Officer and System Owner review; approve or request additional information

Document: justification, compensating controls, risk acceptance, expiry date (max 12 months; extensions require re-approval)

Record in exception register; provide to auditors on request

Review at least quarterly; approve extensions with same rigor

9.2 Rollback

Requirement: Routinely tested, documented rollback procedures support recovery from failed deployments and incidents.

• 9.2.1 Rollback Planning and Testing
• Procedure definition – For critical systems, rollback procedure is defined:
• Redeploy previous artifact
• Revert configuration
• Restore from backup
• As appropriate per system type

Testing frequency – Rollback is tested at least annually for critical systems; semiannually for high-impact systems.

Test evidence – Rollback test produces documentation:

• Date, participants, system/service
• Scenario (artifact rollback, configuration revert, restore)
• Steps executed, validation checks, outcome
• Issues identified and corrective actions

Incident rollback – When a deployment causes an incident, rollback is executed per Incident Response Standards; rollback is itself logged (as emergency change if required).

10. Secrets and Credentials

10.1 Secrets Handling

Principle: Pipelines and automation never embed secrets; all secrets are obtained from the Malawi Government Secrets Management solution at runtime.

10.1.1 Mandatory Requirements

No secrets in repos – Secrets (passwords, API keys, tokens, connection strings) MUST NOT be stored in version-controlled code, configuration files, pipeline definitions, or environment files.

Runtime retrieval – Pipelines and automation integrate with Secrets Management solution to obtain secrets at execution time.

Scanning – Pre-commit or CI scanning (GitHub Advanced Security, Gitguardian, TruffleHog, or equivalent) runs on every commit and detects secrets; merge is blocked until remediated.

Audit – Secret access by pipelines is logged and auditable per Secrets Management Standards.

10.1.2 Secrets Leak Response

If a secret is detected in a repository, pipeline definition, build log, or artifact:

Compromise – Treat as compromised; rotate the credential immediately.

Revoke and update – Revoke old credential and update all systems using it per Secrets Management timelines.

Incident – Raise a security incident per Incident Response Standards; determine if government systems or data were exposed.

Root cause – Address the process gap (missing scanning, training gap, tool configuration issue).

11. Legal Compliance and Training

11.1 Applicable Law

Data Protection Act (2024): Security of processing applies where code and configuration handle personal data.

Electronic Transactions and Cybersecurity Act (2016): Cybersecurity controls and record-keeping support compliance.

Change Management policy: All production changes follow change control and approval per Malawi Government Change Management Standards.

11.2 Training

• All developers, operations engineers, and system administrators involved in delivery SHALL receive training on:
• This standard (objectives, requirements, interdependencies)
• Version control and code review practices
• CI/CD pipeline design and operation
• Secrets handling and integration with Secrets Management
• Change Management integration
• Incident response and rollback procedures
• Baseline configuration management and drift detection

Training is provided at hire and annually; refresher training follows major incidents or policy changes.

12. Verification and Evidence Baseline (Audit-Ready Secure Delivery)

To make this standard auditable, ministries and pipeline owners SHOULD maintain evidence that demonstrates: no secrets in repos (scan results); code review and artifact scanning; baseline and drift remediation; change traceability; SBOM for critical/high; rollback test evidence; exception register. What internal audit checks: Sample of pipelines and deployments for traceability and scanning; baseline and drift; exception register. Sampling: Quarterly sample of systems and pipelines; annual review of exception register. Escalation: Non-compliance → System Owner and Security Officer → remediation plan; repeated → Document Owner and senior management.

12.1 Compliance Reporting

13. Framework Alignment

This standard contributes to compliance with international frameworks:

• ISO/IEC 27001:2013 – control families A.14, A.12, A.9
• NIST SP 800-53 Rev. 5 – families SA, CM, SI, SI-10
• Benchmarks – NIST SP 800-190 (supply chain) as well as general CI/CD guidance

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

14. Appendices

Appendix A: Related Standards

• Malawi Government Change Management and Validation Standards
• Malawi Government Secrets Management Standards
• Malawi Government IAM Standards
• Government Server Security Hardening Standards
• Malawi Government Vulnerability Management Standards
• Malawi Government Incident Response Standards
• Malawi Government Configuration Management Standards
• Malawi Government Container Orchestration Standards

Appendix B: Control and Legal Mapping

• Requirement
• Malawian Law
• Framework
• Version control; code review; change traceability
• Data Protection Act (2024); Electronic Transactions and Cybersecurity Act (2016)
• NIST SP 800-53 Rev. 5: CM-3, SI-7
• Secrets separation; secure handling
• Data Protection Act (2024)
• NIST SP 800-53 Rev. 5: IA-6
• Artifact scanning; SCA
• Electronic Transactions and Cybersecurity Act (2016)
• NIST SP 800-53 Rev. 5: SA-11, SI-3
• Baseline definition; drift detection
• Data Protection Act (2024)
• NIST SP 800-53 Rev. 5: CM-2, CM-3, CM-4
• Approved sources; SBOM; supply chain
• Data Protection Act (2024)
• NIST Software Supply Chain Security Guidance

• Appendix C: Evidence and Artifact Checklist
• Code and automation: Version control; code review approvals; no secrets in repos (scan evidence); pull request/merge request logs.
• Pipelines: Secrets from solution; approval gates configured; scanning results; environment separation evidence; runner security documentation.
• Configuration: Baselines per system type; version control; annual review evidence.
• Drift: Weekly or daily scans; remediation within SLA; exception register with justification and review dates.
• Dependencies: SBOM or inventory for critical systems; scanning in pipeline; remediation per Vulnerability Management; approved source policy.
• Rollback: Defined procedures; annual test evidence; incident rollback logs.
• Appendix D: Templates and Checklists

D.1 Secure Pipeline Design Checklist

• [ ] Pipeline is defined as code in version control
• [ ] Build once; promote same artifact (immutable identifier)
• [ ] Artifacts scanned before production (secrets, dependencies, IaC configs, containers)
• [ ] Critical/high findings block promotion or are excepted with documentation
• [ ] Secrets obtained from Secrets Management solution; none in pipeline code or logs
• [ ] Production deploy requires approval gate + change record reference
• [ ] Environment separation (dev/test creds cannot deploy to production)
• [ ] Runner/agent security: minimal, hardened, patched
• [ ] Rollback procedure defined and tested (critical systems)
• [ ] All deployments logged with artifact, source commit, approver, change record

D.2 Production Deployment Record (Template)

• ``` System/Service: _________________ Environment: Production Date/Time: _________________
• ARTIFACT IDENTIFICATION:
• Artifact type (container/package/binary/config): _______
• Artifact identifier (immutable): _______
• Source repository and commit: _______
• Pipeline run ID: _______
• APPROVAL:
• Change request ID or standard-change ID: _______
• Requester name/identity: _______
• Approver name/identity: _______
• Approval timestamp: _______
• VALIDATION:
• Validation checks performed: _______
• All checks passed: Yes / No
• Evidence links: _______
• ROLLBACK (if applicable):
• Rollback executed: Yes / No
• Previous artifact used: _______
• Rollback outcome: _______
• ```

D.3 Configuration Baseline Template

``` BASELINE IDENTIFICATION:

• System type and role: _______
• Baseline version: _______
• Effective date: _______
• REQUIRED CONFIGURATION: [Table with: Setting | Required Value | Validation Method | CIS/Hardening Reference]
• BASELINES REVIEW:
• Last reviewed: _______
• Review frequency: Annual
• Owner: _______
• Exceptions allowed: Yes / No
• ```

D.4 Drift Report (Template)

``` DETECTION:

• System identifier: _______
• Baseline version: _______
• Scan date: _______
• DRIFT DETAILS:
• Configuration differences: [list]
• Severity: Critical / High / Medium / Low
• CLASSIFICATION:
• Authorized (change record ID): _______
• Unauthorized: _______
• REMEDIATION:
• Actions taken: _______
• Date remediated: _______
• Validation performed: Yes / No
• Evidence links: _______
• ```

D.5 SBOM Record (Template)

``` APPLICATION IDENTIFICATION:

• System/service name: _______
• Owner: _______
• Impact level (Critical/High/Medium/Low): _______
• SBOM GENERATION:
• Build/release identifier: _______
• Source commit: _______
• Tool used: _______ (version)
• Generation date: _______
• SBOM CONTENT: [Table with: Component | Version | Source | License | Direct/Transitive]
• STORAGE:
• Location/repository: _______
• Access controls: _______
• Retrieval instructions: _______
• ```

D.6 Code Review Checklist

• [ ] Logic and design alignment reviewed
• [ ] No hardcoded secrets or credentials
• [ ] No unsafe patterns (SQL injection, unvalidated input, etc.)
• [ ] Configuration aligned with baselines
• [ ] Pre-merge secret scan passed
• [ ] Approver identity documented
• [ ] Pull/merge request link to change record (if production deployment expected)

D.7 Approved Source Registration (Template)

• ``` APPROVED SOURCE POLICY
• APPROVED PACKAGE REGISTRIES:
• [Registry name/URL] - [conditions: internal only, public, with signature verification, etc.]
• Example: Maven Central - public, signature verification required for gov projects
• APPROVED CONTAINER REGISTRIES & BASE IMAGES:
• [Registry name] - [allowed image families or filters]
• Example: Docker Hub Official Images - Alpine, Ubuntu LTS only
• INTEGRITY REQUIREMENTS:
• Signatures required: Yes / No - [which registries]
• Checksum or provenance verification: Yes / No - [where supported]
• EXCEPTION PROCESS:
• Exception request form/template link: _______
• Review authority: Security Officer + System Owner
• Max duration: 12 months
• Compensating controls: [describe minimum expectations]
• ```

References

NIST SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations (CM-2, CM-3, CM-4, SA-11, SI-7, IA-6, SI-3)

• NIST Software Supply Chain Security Guidance
• Data Protection Act No. 3 of 2024 (Malawi)
• Electronic Transactions and Cybersecurity Act (2016) (Malawi)
• CIS Benchmarks
• Malawi Government Change Management Standards
• Malawi Government Secrets Management Standards
• Government Server Security Hardening Standards
• Malawi Government Vulnerability Management Standards