Overview
This document establishes a government-wide framework for security incident response and cyber resilience in Malawi. It defines the incident response lifecycle (detection, classification, containment, eradication, recovery, post-incident review), roles and escalation (including the Computer Incident Response Team (CIRT) and reporting to MACRA under the Data Protection Act), and how incidents are documented and used to improve defences. The framework ensures that all ministries respond to incidents in a consistent, timely, and legally compliant manner. It aligns with the Malawi Government Email Standards (IR section), the Government Server Security Hardening Standards (operational security), NIST SP 800-61 (Computer Security Incident Handling Guide), and Malawian law (Data Protection Act breach notification, Electronic Transactions and Cybersecurity Act).
Strategic Importance
Security incidents (malware, unauthorised access, data breach, ransomware) are inevitable; the quality of response determines how much damage is contained and how quickly services and trust are restored. A single government-wide approach ensures that incidents are classified and handled according to severity, that the right roles (technical, legal, communications) are engaged, and that legal obligations (e.g. breach notification to MACRA within 72 hours) are met. Without a common framework, ministries may respond inconsistently and miss reporting or containment deadlines.
Key Benefits
A unified incident response framework reduces impact through clear containment and eradication procedures and through coordination with CIRT and other ministries. It supports legal compliance: the Data Protection Act requires breach notification to MACRA and (where high risk) to data subjects; this standard defines how and when that is done. Cyber resilience is improved when post-incident reviews lead to better controls, training, and preparation. Integration with the Malawi Government Email Standards, Server Hardening, Backup and Recovery, and Monitoring and Observability standards ensures that detection, evidence, and recovery capabilities are in place before incidents occur.
Description
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 detects, classifies, contains, eradicates, and recovers from security incidents, and how it reports incidents to authorities and learns from them. It covers the incident response lifecycle, roles and responsibilities, escalation paths, communication (internal and external), and coordination with the national CIRT and with MACRA. It is intended to be used by all ministries and by vendors or contractors when they are responsible for government systems or data.
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 have access to government systems or data. It covers incidents affecting confidentiality, integrity, or availability of government systems or data, including malware, unauthorised access, data breach, ransomware, denial of service, and misuse. It applies regardless of whether the affected system is on-premises, in government cloud, or vendor-managed where the government retains responsibility.
1.3 Definitions and Key Terms
Security incident – An event that actually or potentially compromises the confidentiality, integrity, or availability of government systems or data (e.g. malware, unauthorised access, data breach, ransomware, denial of service, misuse).
Incident response lifecycle – The phases of response: detection, classification, containment, eradication, recovery, and post-incident review; may iterate as the incident evolves.
Containment – Actions taken to limit the spread or impact of an incident (e.g. isolate affected systems, revoke credentials, block malicious traffic); critical incidents contained within 1 hour, high within 4 hours where applicable.
Eradication – Removal of the cause of the incident (e.g. malware removal, closing attack vector); followed by recovery and hardening to prevent recurrence.
Breach notification – Reporting to MACRA (and where high risk to data subjects) per Data Protection Act (2024); reportable breaches notified within 72 hours of discovery.
CIRT (Computer Incident Response Team) – The government or ministry team that coordinates incident response, escalation, and (where applicable) cross-government coordination.
Post-incident review – Analysis after an incident to determine root cause, effectiveness of response, and corrective actions; 100% of critical and high incidents have review within 2 weeks.
Cyber resilience – The ability to detect, respond to, and recover from incidents and to improve defences based on lessons learned.
2. Core Objectives and Success Metrics
2.1 Primary Objectives
Timely detection and containment – Incidents are detected and classified; critical contained within 1 hour, high within 4 hours (per Server Hardening IR timelines where applicable) to limit damage.
Legal compliance – Reportable breaches notified to MACRA within 72 hours; notification to data subjects where high risk; evidence preserved per Logging and Evidence Standards.
Consistent response – All ministries follow the same lifecycle, roles, and escalation; CIRT and Security Officer engaged per classification; coordination with Backup and Recovery for restore.
Learning and improvement – Post-incident review for 100% of critical and high incidents; corrective actions tracked to closure; defences improved to reduce recurrence.
Integration – Incident response aligns with Monitoring (detection, SIEM), Logging and Evidence (preservation), Backup and Recovery (restore), and Email Standards (IR section); readiness maintained per Server Hardening.
2.2 Key Performance Indicators (KPIs)
| Metric | Target | Definition | Data source | Owner | Cadence | Action on breach | Strategic Rationale |
|---|---|---|---|---|---|---|---|
| Detection to containment | Critical: within 1 hour; High: within 4 hours | Time from detection to containment; % within SLA | Incident register; timestamps | CIRT; Security Officer | Per incident; monthly report | Post-incident review; improve process | Limits damage |
| Breach notification | 100% of reportable breaches notified to MACRA within 72 hours of discovery | Reportable breaches notified within 72 hours | Notification records; incident register | Legal; CIRT | Per breach | Notify within 72 hours; document delay | Legal compliance |
| Post-incident review | 100% of critical and high incidents have post-incident review within 2 weeks | % of critical/high with PIR within 2 weeks | PIR records; incident register | CIRT; System Owner | Per incident | Complete PIR; document exception | Learning and improvement |
| Corrective actions | Corrective actions from reviews tracked to closure within agreed timeframe | % of corrective actions closed within due date | Action tracker; PIR | CIRT; System Owner | Monthly | Escalate; extend with approval | Reduces recurrence |
| Incident register | 100% of detected incidents recorded with classification and outcome | All incidents in register with classification and outcome | Incident register | CIRT | Continuous; audit sample | Complete record; correct classification | Supports audit and trend analysis |
2.3 Minimum Baseline and Prohibitions
Minimum controls (floor): All detected incidents SHALL be recorded with classification and outcome. Critical incidents SHALL be contained within 1 hour; High within 4 hours where applicable. Reportable breaches (personal data) SHALL be notified to MACRA within 72 hours of discovery. Critical and high incidents SHALL have post-incident review within 2 weeks; corrective actions tracked to closure. All exceptions SHALL be in the exception register. Prohibitions: MUST NOT delay breach notification beyond 72 hours without Legal approval. 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 standard and is responsible for its maintenance, interpretation, and coordination with other government standards (including Backup and Recovery, Monitoring, and Logging and Evidence).
System Owner – Accountable for incidents affecting their systems; approves exception requests; supports containment, eradication, and recovery decisions; involved in breach notification where their data is affected.
Security Officer – Validates incident response process and readiness; governs exceptions; may lead or coordinate response for high/critical incidents.
CIRT or incident response lead – Coordinates detection, classification, containment, eradication, recovery, and post-incident review; escalates to MACRA and senior management per classification; maintains incident register and corrective action tracking.
Legal and communications – Legal advises on breach notification and evidence; communications (internal/external) per policy for significant incidents.
3.2 Compliance Framework
Incident response must align with: Data Protection Act (2024) – breach notification to MACRA, notification to data subjects where high risk, security measures; Electronic Transactions and Cybersecurity Act (2016) – cybersecurity and record-keeping; Government Server Security Hardening Standards – incident response readiness, forensic capability; NIST SP 800-61 (Computer Security Incident Handling Guide); NIST SP 800-53 Rev. 5 (IR family); and Malawi Government Backup and Recovery, Monitoring, and related standards.
3.3 Incident Classification
Critical: Nation-state or major breach affecting more than 1000 citizens; critical service down; immediate threat to life or safety. Response: immediate (e.g. containment within 1 hour); CIRT and senior management engaged; MACRA and other authorities as required. High: Malware, unauthorised access, significant data breach, or service disruption. Response: urgent (e.g. containment within 4 hours); CIRT and Security Officer engaged; MACRA if personal data breach. Medium: Policy violation, suspicious activity, limited impact. Response: standard (e.g. within 24 hours). Low: Minor event, user education needed. Response: normal (e.g. within 3 days). Classification may be updated as the incident is better understood.
3.4 Safe Exception Process
Exceptions to mandatory incident response requirements (e.g. containment timeline, breach notification procedure) 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. Incident Response Lifecycle
4.1 Detection
Incidents are detected via monitoring (IDS/IPS, SIEM, logs), user report, vendor or partner notification, or external disclosure. All detection channels must route to a single point (e.g. ministry IR lead, helpdesk, or CIRT) so that incidents are not missed. Detection is logged with date, time, source, and initial description.
4.2 Classification and Triage
The incident is classified (critical, high, medium, low) based on impact (systems/data affected, number of users, sensitivity) and urgency (active threat, ongoing exfiltration). Classification determines response timeline and who is engaged. Triage may involve technical assessment (what happened, what is affected) and business impact (which services, which data). Classification is documented and may be updated.
4.3 Containment
Containment actions limit spread and damage. Short-term containment may include: isolating affected systems from the network; disabling compromised accounts (per IAM); blocking malicious IPs or domains at firewall; taking affected systems offline. Long-term containment may include: rebuilding systems from clean backup or image; applying patches; strengthening access controls. Containment actions are documented; evidence is preserved where needed for investigation or legal (e.g. forensic image before rebuild). Coordination with CIRT and System Owner ensures that containment does not conflict with business continuity where alternatives exist.
Procedure: (1) Upon classification, initiate containment per severity (critical: within 1 hour; high: within 4 hours). (2) Document all containment actions with timestamp and authority; preserve forensic evidence before rebuild where required. (3) Coordinate with System Owner and CIRT; record decisions in incident record. (4) Escalate to MACRA within 72 hours where personal data breach is reportable. (5) Retain incident and containment documentation for audit per Logging and Evidence Standards.
4.4 Eradication
Eradication removes the cause of the incident: malware is removed (or system rebuilt); vulnerability is patched; compromised credentials are rotated (per Secrets Management and IAM). Affected systems are verified clean before return to production. Eradication steps are documented.
4.5 Recovery
Systems are returned to production with increased monitoring. Recovery may use backups (per Malawi Government Backup and Recovery Standards) or clean rebuild. Recovery is validated (functionality, no reinfection). Services are restored in priority order (critical first). Recovery is documented and communicated to stakeholders.
4.6 Post-Incident Review
Within two weeks of closure (or as soon as practicable for critical incidents), a post-incident review is held. Attendees include technical staff, System Owner, Security Officer, and (where appropriate) legal and communications. The review covers: what happened; what was done well; what could be improved; root cause; and corrective actions (process, technical, training). Corrective actions are assigned with owners and due dates and are tracked to closure. Summary (anonymised if needed) may be shared across government to improve collective resilience.
5. Data Breach and Notification
5.1 Data Protection Act (2024) Obligations
Where an incident involves a personal data breach (accidental or unlawful destruction, loss, alteration, or unauthorised disclosure of or access to personal data), the Data Protection Act may require notification to MACRA (as Data Protection Authority). Notification must be made within the period specified in the Act (typically 72 hours of discovery where the Act so requires). Notification content should include: nature of the breach; categories and approximate number of data subjects affected; likely consequences; measures taken or proposed to address the breach and mitigate harm. If the breach poses high risk to the rights and freedoms of individuals, data subjects must be notified without undue delay. Legal and the ministry’s data protection lead should be engaged to determine exact obligations and wording.
5.2 Other Reporting
Other reporting may be required by policy or law (e.g. to law enforcement for criminal activity, to Cabinet or senior government for major incidents). CIRT and Legal can advise. Internal reporting (to CIRT, to MoICT, to ministry head) follows escalation paths defined in this standard and in ministry procedures.
6. Communication and Coordination
6.1 Internal Communication
Incident status is communicated to System Owner, Security Officer, CIRT (for critical/high), and management as appropriate. Updates are provided at defined intervals until the incident is closed. Communication is factual and avoids speculation; it is coordinated so that conflicting messages are not sent.
6.2 External Communication
External communication (press, public, partners) is approved and coordinated. A single spokesperson or process ensures consistent messaging. Communication with data subjects (breach notification) follows Data Protection Act requirements and legal advice. Communication with MACRA and other authorities follows law and official channels.
6.3 Coordination with CIRT and Other Ministries
Critical and high incidents are reported to CIRT. CIRT may provide technical support, coordinate with other ministries if the incident crosses boundaries, and liaise with national or international bodies. Ministries provide CIRT with necessary information (without disclosing more than needed) and follow CIRT guidance where applicable.
7. Verification and Evidence Baseline (Audit-Ready Incident Response)
To make this standard auditable, ministries and CIRT SHOULD maintain evidence that demonstrates: incident register (classification, outcome); containment and breach notification timeliness; post-incident reviews and corrective actions; exception register. What internal audit checks: Sample of incidents for lifecycle and PIR; breach notification evidence; exception register. Sampling: Quarterly sample of incidents; annual review of exception register. Escalation: Non-compliance → Security Officer and CIRT lead → remediation plan; repeated → Document Owner and senior management.
7.1 Compliance Reporting
| Cadence | Content |
|---|---|
| Monthly | Incident count by severity; containment and breach notification timeliness; PIR completion; corrective action status. |
| Quarterly | Trend; exception review outcomes; recommendations. |
| Annual | Full compliance review; year-over-year comparison; presentation to senior management. |
8. Legal Compliance and Training
7.1 Legal and Related Standards
Data Protection Act (2024) – breach notification, security measures, accountability. Electronic Transactions and Cybersecurity Act (2016) – cybersecurity, record-keeping. Related standards: Malawi Government Email Standards (IR section); Government Server Security Hardening Standards; Malawi Government Backup and Recovery Standards; Malawi Government Monitoring and Observability Standards; Malawi Government IAM and Secrets Management (credential revocation, rotation).
7.2 Training
Incident response leads and technical staff are trained on this standard, on their roles, and on detection, containment, eradication, and recovery procedures. Training includes breach notification and evidence preservation. Tabletop or simulation exercises are conducted at least annually for critical systems or ministries. Training is refreshed when procedures or law change.
9. Framework Alignment
This standard contributes to compliance with international frameworks:
- ISO/IEC 27001:2013 – control families A.16, A.17, A.18
- NIST SP 800-53 Rev. 5 – families IR, CP, CA, AU
- Benchmarks – none specific
Refer to `ISO27001_Mapping.md` and `Multi_Framework_Mapping.md` for the complete mapping tables.
10. Appendices
Appendix A: Incident Report Form (Summary)
Date/time discovered; reported by; severity; description; affected systems/data; actions taken; requested support. (Full form per Malawi Government Email Standards Appendix D or ministry template.)
Appendix B: Related Standards
Malawi Government Email Standards. Government Server Security Hardening Standards. Malawi Government Backup and Recovery Standards. Malawi Government Monitoring and Observability Standards. Malawi Government IAM Standards. Malawi Government Secrets Management Standards. Data Protection Act (2024); MACRA breach notification guidance.
Appendix C: Escalation and Notification Quick Reference
| Classification | Containment target | Escalation | MACRA / external |
|---|---|---|---|
| Critical | Within 1 hour | CIRT + senior management | As required (e.g. breach, national CIRT) |
| High | Within 4 hours | CIRT + Security Officer | Breach notification if personal data affected |
| Medium | Within 24 hours | IR lead + System Owner | — |
| Low | Within 3 days | IR lead or helpdesk | — |
Breach notification to MACRA within 72 hours of discovery where the incident constitutes a reportable personal data breach under the Data Protection Act (2024).
Appendix D: Control and Legal Mapping
| Requirement summary | Malawian law (Act, section/regulation) | Framework reference |
|---|---|---|
| Detection; classification; containment; breach notification | Data Protection Act (2024), breach notification to MACRA; Electronic Transactions and Cybersecurity Act (2016) | NIST SP 800-61; NIST SP 800-53 Rev. 5: IR family |
- Appendix E: Evidence and Artifact Checklist
- Incident records: Detection, classification, containment, recovery, and post-incident review; breach notification to MACRA where required.
- Exception register: Requirement, justification, compensating controls, risk acceptance, and review/expiry dates.
- Appendix F: Playbooks and Templates (Minimum)
F.1 Common Incident Playbook List (Minimum Set)
Ministries SHOULD maintain playbooks for at least:
- Phishing / mailbox compromise
- Credential leak (secrets in repo)
- Ransomware / destructive malware
- Unauthorised access / privilege escalation
- Data exposure (e.g. public storage, misconfiguration)
- Denial of service impacting critical service
F.2 Internal Status Update (Template)
- Incident ID and classification
- Known facts (what/when/impact)
- Actions taken and current containment status
- Next steps and owner
- Next update time
F.3 Exercise After-Action Report (Template)
- Scenario and scope
- Objectives and success criteria
- Timeline and decisions
- Gaps identified and corrective actions (owner + due date)
References
Data Protection Act No. 3 of 2024 (Malawi).
Electronic Transactions and Cybersecurity Act (2016) (Malawi).
Malawi Government Email Standards.
Government Server Security Hardening Standards.
NIST SP 800-61, Computer Security Incident Handling Guide.
NIST SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations (IR family).