Vulnerability 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 identifies, assesses, prioritises, and remediates vulnerabilities in government systems (operating systems, applications, firmware, network devices). It covers scanning and assessment, prioritisation (e.g. CVSS, system criticality), remediation timelines (aligned with Government Server Security Hardening Standards), exception handling, and reporting. It applies to all in-scope government systems regardless of hosting model.

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 government systems. It covers infrastructure, applications, and (where feasible) third-party or vendor components. Scanning and remediation may be performed by central IT, ministry IT, or vendors under contract; accountability remains with System Owner.

1.3 Definitions and Key Terms

Vulnerability – A weakness in an asset (e.g. software, firmware, configuration) that can be exploited to compromise confidentiality, integrity, or availability; identified by scanning, assessment, or disclosure.

Vulnerability scanning – Automated discovery of known vulnerabilities (e.g. CVE) in systems; performed regularly (e.g. monthly for critical systems); authenticated scans where possible for accuracy.

CVSS (Common Vulnerability Scoring System) – A standard for scoring vulnerability severity (e.g. 0–10); used with system impact to prioritise remediation (e.g. Critical 9–10, High 7–8.9, Medium 4–6.9).

Remediation – Action to eliminate or mitigate a vulnerability (e.g. applying a patch, configuration change, or compensating control); planned and executed as a change per Change Management.

Exception – Documented, time-limited acceptance of delayed remediation when timeline cannot be met; requires justification, compensating controls, risk acceptance by System Owner and Security Officer, and quarterly review.

Patch – A fix (software update) supplied by a vendor to address a vulnerability; applied per Government Server Hardening patch timelines (e.g. Critical within 15 days, High within 30 days).

Compensating control – A control that reduces risk when primary remediation (e.g. patch) is not yet possible; documented in exception and reviewed until remediation is complete.

2. Core Objectives and Success Metrics

2.1 Primary Objectives

Visibility – All in-scope systems are scanned at least monthly (critical/high-impact) or quarterly minimum; vulnerabilities are aggregated, prioritised, and tracked until remediated or excepted.

Timely remediation – Critical (CVSS 9–10) remediated within 15 days; High (7–8.9) within 30 days; Medium (4–6.9) within 90 days per Government Server Security Hardening Standards.

Accountability – Exceptions are documented with justification, compensating controls, risk acceptance, and review date; exception register is maintained and auditable.

Integration – Vulnerability management drives patching (Server Hardening), changes (Change Management), and baseline updates (Configuration Management); exploitation is treated as an incident (Incident Response).

Continuous improvement – Backlog of overdue critical/high decreases over time; zero-day or actively exploited vulnerabilities trigger emergency patching per policy.

2.2 Key Performance Indicators (KPIs)

2.3 Minimum Baseline and Prohibitions

• Minimum controls (floor for all ministries):
• Scanning: All in-scope systems (Critical/High impact) SHALL be scanned at least monthly; authenticated scans where possible; coverage documented and auditable.
• Remediation: Critical (CVSS 9–10) remediated within 15 days; High (7–8.9) within 30 days; Medium (4–6.9) within 90 days per Government Server Security Hardening Standards.
• Exception: When timeline cannot be met, exception SHALL be requested with justification, compensating controls, risk acceptance (System Owner + Security Officer), and quarterly review; all exceptions in register.
• Evidence: Scan results and remediation evidence SHALL be retained for at least 12 months for audit.

Zero-day/active exploitation: Emergency patching process SHALL be triggered per Server Hardening; expedited testing and deployment.

Tiering (system impact):

• Tier
• Scan frequency
• Critical (9–10)
• High (7–8.9)
• Medium (4–6.9)
• Critical
• Monthly minimum
• 15 days
• 30 days
• 90 days
• High
• Monthly
• 15 days
• 30 days
• 90 days
• Medium/Low
• Quarterly minimum
• 15 days
• 30 days
• 90 days
• Prohibitions:

MUST NOT leave critical or high vulnerabilities unremediated beyond SLA without an approved exception (justification, compensating controls, review date).

MUST NOT grant exception without recording in exception register with risk acceptance and expiry.

MUST NOT exclude in-scope systems from scanning without documented exception.

MUST NOT discard scan or remediation evidence before 12 months without legal/retention approval.

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 Government Server Security Hardening, Change Management, and Incident Response).

System Owner – Accountable for remediation of vulnerabilities on their systems; approves exceptions and risk acceptance within their remit.

Security Officer – Validates that vulnerability management process and remediation timelines meet this standard; governs exceptions; receives reporting.

Vulnerability or security analyst – Runs scans, aggregates and prioritises results, tracks remediation and exceptions, reports to System Owner and Security Officer; coordinates with Change Management for patches.

System Administrator – Implements remediation (patch, config change) per Change Management; supports exception documentation and compensating controls.

3.2 Scanning and Assessment

Vulnerability scanning is performed regularly (at least monthly for critical and high-impact systems; quarterly minimum for others). Scans are authenticated where possible for accuracy. Results are aggregated, deduplicated, and prioritised. Penetration testing or red-team exercises may be performed annually or after significant change per policy; findings are treated as high-priority vulnerabilities. Zero-day or actively exploited vulnerabilities trigger emergency patching per Server Hardening (expedited testing and deployment).

• 3.2.1 Runbook: Vulnerability Scan and Remediation Cycle
• Element
• Content
• Trigger

Scheduled (monthly for Critical/High systems; quarterly for others); or on-demand after major change.

Prerequisites

Scan platform; asset inventory; access to systems for authenticated scan; Change Management process for patches.

Steps

1. Run authenticated scans per coverage model (3.2.4); aggregate and deduplicate results. 2. Prioritise by CVSS and system impact; create remediation tasks (critical 15 days, high 30 days, medium 90 days). 3. Link remediation to Change Management (patch/change record); track to closure. 4. Where timeline cannot be met: request exception (justification, compensating controls); obtain System Owner and Security Officer sign-off; add to exception register; review quarterly. 5. Verify remediation (re-scan or validation); close task; retain scan and remediation evidence 12 months. 6. Report metrics (coverage, backlog, overdue) to Security Officer.

Validation

Scan completed; critical/high remediated within SLA or exception in register; evidence retained.

Rollback / failure

If patch causes outage: rollback per Change Management; document; re-plan remediation.

Evidence

Scan report; remediation tickets; change records; exception register entries; re-scan proof.

• 3.2.2 Runbook: Exception Request and Quarterly Review
• Element
• Content
• Trigger

Remediation cannot be completed within SLA (no patch, business constraint, testing delay); or quarterly exception review.

Prerequisites

Exception request form (Appendix D.2); System Owner and Security Officer availability; exception register.

Steps

1. Document: vulnerability (CVE/ID), affected assets, reason timeline cannot be met, compensating controls (specific), monitoring. 2. Risk acceptance: System Owner and Security Officer sign-off; set expiry (max 12 months) and remediation milestones. 3. Record in exception register; schedule quarterly review. 4. At review: reassess; extend with re-approval or close when remediated; update register.

Validation

Exception has justification, compensating controls, risk acceptance, expiry; register updated; quarterly review done.

Rollback / failure

If exception lapses without review: escalate to Security Officer; revoke or re-approve; remediate or extend with documentation.

Evidence

Exception request form; register entry; quarterly review records.

• 3.2.3 Runbook: Emergency Patching (Zero-Day / Actively Exploited)
• Element
• Content
• Trigger

Zero-day or actively exploited vulnerability affecting government systems; or directive from Security Officer/CIRT.

Prerequisites

Emergency change process; patch or mitigation from vendor or authoritative source; test environment where feasible.

Steps

1. Confirm vulnerability and affected assets; assess exposure (internet-facing, sensitive data). 2. Obtain patch or mitigation; expedited testing in non-prod where possible (or accept risk per policy). 3. Deploy per emergency Change Management; prioritise Critical/High impact and internet-facing. 4. Verify (re-scan or validation); document in vuln tracker and change record. 5. Post-incident: if exploited, follow Incident Response; document lessons learned.

Validation

Patch or mitigation applied to in-scope systems; verification complete; change and vuln records updated.

Rollback / failure

If patch causes critical outage: rollback; document; apply alternative mitigation until stable patch available.

Evidence

Emergency change record; scan before/after; incident record if exploited.

• 3.2.4 Scan Coverage Model (Baseline)
• Ministries SHOULD document scan coverage by asset type. At minimum:
• Asset type
• Scan type
• Minimum cadence (recommendation)
• Notes
• Servers/VMs
• Authenticated vuln scan
• Monthly (Critical/High)
• Align with patch SLAs
• Network devices
• Firmware/config vuln scan
• Monthly/Quarterly
• Include perimeter devices
• Web apps/APIs
• DAST (where applicable)
• Before production for critical/internet-facing
• Also periodic re-test
• Containers/images
• Image scan
• Every build
• Block promotion per CI/CD policy
• Dependencies
• SCA scan
• Every build
• SBOM supports response

Coverage SHALL be auditable (what assets are in scope; what is scanned; evidence retained).

3.3 Prioritisation

Prioritisation considers: CVSS (or equivalent) score; whether exploit is known or in the wild; system impact (critical/high-impact systems first); and dependency (e.g. critical library). Critical (CVSS 9–10) and High (7–8.9) are remediated within 15 and 30 days respectively per Government Server Security Hardening Standards; Medium (4–6.9) within 90 days. Compensating controls are documented when timelines cannot be met.

3.4 Remediation and Exception

Remediation is planned and executed as a change (Change Management). Patch testing is performed in non-production before production where feasible. When remediation cannot be completed within the timeline (e.g. no patch available, business constraint), an exception is requested: justification, compensating controls, risk acceptance by System Owner and Security Officer, and maximum duration (e.g. 12 months) with quarterly review. Exception register is maintained and auditable.

3.5 Reporting and Integration

Vulnerability status (open, remediated, exception) is reported to System Owner, Security Officer, and (where required) senior management. Metrics (backlog, mean time to remediate, exception count) are tracked. Integration with Incident Response: when a vulnerability is exploited, it is treated as an incident; post-incident review includes why remediation was delayed if applicable.

3.6 Safe Exception Process

Exceptions to remediation timelines (see 3.4) 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 (requirement, justification, compensating controls). Documentation: justification; compensating controls and remediation 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 Vulnerability Management)

To make this standard auditable, ministries and vulnerability/security analysts SHOULD maintain evidence that, at minimum, demonstrates:

• Scan coverage: Asset inventory and scan scope; scan frequency and last scan date per asset type; scan reports retained 12 months.
• Remediation: Remediation records (vuln ID, asset, action, change record, closure date); proof that critical/high met SLA or have valid exception.
• Exceptions: Exception register with requirement, justification, compensating controls, risk acceptance, expiry, quarterly review.
• Emergency patching: Emergency change records and verification for zero-day/actively exploited handling.
• What internal audit checks: (1) Scan coverage and frequency; (2) sample of critical/high vulnerabilities for remediation or exception; (3) exception register validity and review; (4) retention of scan and remediation evidence.
• Sampling approach: Quarterly sample of systems for scan history; quarterly sample of open critical/high for SLA or exception; annual review of exception register.
• Escalation path: Non-compliance (e.g. overdue critical without exception) → 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 Standards

Electronic Transactions and Cybersecurity Act (2016): cybersecurity measures; vulnerability management is a core control.

• Related standards: Government Server Security Hardening Guide (`server-hardening/server-hardening-guide.md`); Malawi Government Change Management Guide (`change-management/change-management-guide.md`); Malawi Government Incident Response Guide (`incident-response/incident-response-guide.md`).
• Training: System Owners, Security Officers, and operations on this standard, prioritisation, exception process, 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.12, A.9, A.18
• NIST SP 800-53 Rev. 5 – families RA, SI, CA
• Benchmarks – CIS Vulnerability Assessment Benchmark

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

7. Appendices

Appendix A: Related Standards

Government Server Security Hardening Guide; Malawi Government Change Management Guide; Malawi Government Incident Response Guide.

Appendix B: Control and Legal Mapping

• Appendix C: Evidence and Artifact Checklist
• Scanning: Evidence of scan coverage (critical/high-impact systems); scan frequency and results.
• Remediation: Remediation records and timelines; patch testing where applicable.
• Exceptions: Exception register with requirement, justification, compensating controls, risk acceptance, and review/expiry dates.
• Appendix D: Templates (Minimum)

The following templates SHOULD be used as standard formats: Vulnerability Remediation Record (D.1); Exception Request for Delayed Remediation (D.2); Exception request content (Section 3.6).

D.1 Vulnerability Remediation Record (Template)

• Vulnerability identifier (CVE/tool ID) and severity
• Asset/system and owner
• Exposure context (internet-facing, privileged access, sensitive data)
• Planned remediation action and change record link
• Verification method (re-scan/validation)
• Closure evidence and date

D.2 Exception Request for Delayed Remediation (Template)

• Vulnerability and affected assets
• Reason timeline cannot be met
• Compensating controls (specific) and monitoring
• Risk acceptance (System Owner + Security Officer)
• Expiry date and remediation milestones

References

NIST SP 800-40, Managing Security Patches.

NIST SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations (RA-5, SI-2).

Government Server Security Hardening Standards.

Malawi Government Change Management Standards.

Malawi Government Configuration Management Standards.

Malawi Government Incident Response Standards.

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

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