Logging, Retention and Evidence 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 cross-cutting rules for what to log, how long logs are retained, and how log integrity and evidence are managed. It complements system-specific logging (e.g. Malawi Government Monitoring and Observability Standards, Government Server Security Hardening Standards) by setting retention, FOI, Data Protection, and evidence-handling requirements that apply across government systems.

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 systems that generate logs for government. It covers security logs, audit logs, application logs, and other logs that may be needed for monitoring, audit, incident response, or legal proceedings.

1.3 Definitions and Key Terms

Log – A time-ordered record of events generated by a system, application, or device; used for monitoring, audit, incident response, and legal proceedings; may contain security, access, or audit data.

Retention – The period for which logs are kept; set per log type and aligned with Electronic Transactions and Cybersecurity Act (record-keeping), FOI (government records), Data Protection Act (personal data in logs), and operational need.

Integrity – Protection of logs from modification (e.g. access control, write-once or append-only storage, hashing or signing) so that logs can be relied upon as evidence; supports non-repudiation.

Non-repudiation – The assurance that the origin and content of a log entry cannot be denied; supported by integrity controls and chain of custody.

Chain of custody – Documented record of how log evidence was collected, stored, and transferred when used for investigation or legal proceedings; maintains admissibility.

Legal hold – Suspension of normal log deletion when litigation, investigation, or regulatory request requires preservation; scope and duration documented; Legal and System Owner involved.

Evidence – Logs (and related data) that may be used for audit, incident response, or legal proceedings; must be retained per policy and protected for integrity; chain of custody when extracted.

Personal data in logs – Log entries that relate to an identified or identifiable person; minimised (log only what is necessary); lawful basis and retention documented per Data Protection Act; secure deletion when retention ends.

2. Core Objectives and Success Metrics

2.1 Primary Objectives

Defined retention – All log types have a defined retention period aligned with law and policy; logs are available when needed and securely deleted or anonymised when retention ends.

Integrity and non-repudiation – Critical and security logs are protected from tampering (access control, integrity mechanism); chain of custody when logs are used as evidence.

Legal and FOI compliance – Retention supports Electronic Transactions and Cybersecurity Act (record-keeping), FOI (retrieval within response period where logs are government records), and Data Protection Act (personal data in logs); legal hold procedure documented and used when required.

Cross-cutting consistency – Log scope is defined per Monitoring and Server Hardening; this standard sets retention, integrity, and evidence-handling rules that apply across government systems.

Evidence readiness – Logs can serve as evidence for audit, incident response, and legal proceedings; procedures for preservation, extraction, and chain of custody are in place.

2.2 Key Performance Indicators (KPIs)

2.3 Minimum Baseline and Prohibitions

• Minimum controls (floor for all ministries):
• Retention: Every log category in use SHALL have a defined retention period documented in a retention schedule, aligned with Electronic Transactions and Cybersecurity Act, FOI, and Data Protection Act. Minimum: 90 days online for security/audit logs; archive period as per policy (e.g. 7 years for audit-relevant logs unless law specifies otherwise).
• Integrity: Authentication and access logs, privileged/admin action logs, and security detection logs SHALL be protected from modification (access control; append-only or write-once storage where feasible; integrity verification where required for high-assurance).
• Legal hold: A documented procedure SHALL exist for applying legal hold (scope, duration, authority); normal deletion suspended when hold is in effect; chain of custody when logs are extracted.
• Exception register: All exceptions to mandatory retention or integrity requirements SHALL be recorded in an exception register (system, requirement, justification, owner, expiry, review date) and made available for audit.

Tiering (where system impact is used):

• Tier
• Retention (audit-relevant)
• Integrity
• Legal hold
• Critical
• Per policy; minimum 90 days online + archive
• Mandatory access control + integrity mechanism; signed/hashed where required
• Mandatory procedure; chain of custody mandatory
• High
• Per policy; minimum 90 days online + archive
• Access control + append-only or integrity where feasible
• Mandatory procedure; chain of custody when extracted
• Medium / Low
• Per retention schedule; minimum 90 days for security logs
• Access control; integrity where feasible
• Procedure available; chain of custody when extracted
• Prohibitions:

MUST NOT retain logs containing personal data beyond the period justified by lawful basis and documented in the retention schedule, unless legal hold applies.

MUST NOT alter or delete logs that are under legal hold.

MUST NOT extract or transfer log evidence for investigation or legal proceedings without documenting chain of custody.

MUST NOT grant exception to retention or integrity without recording in the 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 Monitoring and Observability, Backup and Recovery, and Incident Response).

System Owner – Accountable for logs generated by their systems; ensures retention and integrity meet this standard; supports legal hold when required.

Security Officer – Validates that logging, retention, and evidence controls meet this standard and governs exceptions.

Log or SIEM operator – Manages log collection, retention, and archival; applies integrity controls; supports legal hold and chain of custody when logs are extracted for investigation or legal proceedings.

Legal – Involved when legal hold is applied; advises on retention and admissibility.

3.2 What to Log

Log scope is defined per system type and classification (security events, access, configuration change, errors, etc.) per Malawi Government Monitoring and Observability and Server Hardening. This standard does not duplicate scope but requires that retention and integrity apply to those logs. Personal data in logs is minimised (log only what is necessary); where personal data is logged, lawful basis and retention are documented per Data Protection Act.

3.3 Retention

Retention periods are set per log type and system impact. Minimum retention (e.g. 90 days online, 7 years archived for audit-relevant logs per Government Server Security Hardening) is met. Retention is aligned with: Electronic Transactions and Cybersecurity Act (record-keeping); Freedom of Information Act (government records); Data Protection Act (personal data in logs—retain only as long as necessary, then delete or anonymise); and operational need (incident response, audit). When retention ends, logs are securely deleted or anonymised unless legal hold applies.

• 3.3.1 Log Retention Schedule (Baseline Categories)
• Ministries SHOULD define an explicit retention schedule by log category. At minimum, the schedule should cover:
• Log category
• Examples
• Retention approach (define per tier)
• Authentication and access
• logins, MFA events, access denied
• Online + archive; supports audit and investigations
• Privileged/admin actions
• role changes, config changes, admin commands
• Online + archive; strongest integrity controls
• Security detections
• IDS/IPS alerts, EDR alerts, malware detections
• Online + archive; linked to incident records
• Application audit logs
• data access events, business-critical actions
• Retain per audit/FOI needs where applicable
• Operational logs
• performance logs, debug logs
• Shorter retention unless needed for investigations

Where logs contain personal data, the schedule SHALL justify retention and include secure deletion/anonymisation when retention ends, unless legal hold applies.

3.4 Integrity and Non-Repudiation

Logs are protected from modification: access control (only authorised personnel and systems can write or read); write-once or append-only storage where feasible; integrity verification (e.g. hashing, signed logs) where required for high-assurance. Chain of custody is documented when logs are extracted for investigation or legal proceedings. This supports the Electronic Transactions and Cybersecurity Act (integrity of electronic records) and legal admissibility.

3.5 Legal Hold and Evidence

When litigation, investigation, or regulatory request requires preservation of logs, a legal hold is applied: normal deletion is suspended for the relevant systems and log types; scope and duration are documented; Legal and System Owner are involved. Access to preserved logs is controlled and logged. Chain of custody is maintained when logs are copied or transferred.

• 3.5.1 Runbook: Legal Hold Application
• Element
• Content
• Trigger

Legal, regulator, or authorised body notifies that logs must be preserved (litigation, investigation, or regulatory request).

Prerequisites

Legal hold request form or written authority; access to retention/SIEM configuration; System Owner and Legal identified.

Steps

1. Receive and document the legal hold (requestor, authority, reason, systems/log categories in scope, start date, expected duration). 2. Obtain sign-off from Legal and System Owner. 3. Identify all systems and log categories in scope; suspend automatic deletion for those sources (adjust retention or disable purge for hold period). 4. Restrict access to preserved logs to authorised personnel only; log all access. 5. Set review date; extend or release hold per Legal instruction. 6. When hold is released, resume normal retention and deletion per schedule.

Validation

Deletion suspended for in-scope systems; access restricted and logged; hold documented in legal hold register.

Rollback / failure

If scope was wrong: correct scope with Legal; document. If deletion occurred before hold: escalate to Legal; preserve remaining logs; document incident.

Evidence

Legal hold request/approval form; legal hold register entry; configuration change records (retention suspension); access logs.

• 3.5.2 Runbook: Chain of Custody for Log Extraction
• Element
• Content
• Trigger

Logs must be extracted and provided to investigation team, Legal, or external party for incident response or legal proceedings.

Prerequisites

Authority to extract (e.g. Legal, CIRT, System Owner); chain of custody form (Appendix D.2); access to logs and secure transfer method.

Steps

1. Record evidence identifier, source system(s), collection method, and date/time. 2. Generate hash/checksum of extracted dataset where applicable. 3. Record collector identity and storage location; apply access controls. 4. For each transfer (to investigator, Legal, etc.): record from/to, by whom, date/time on chain of custody form. 5. Retain completed chain of custody form with evidence package; do not alter original logs in place.

Validation

Chain of custody form complete; hash recorded; all transfers documented; form retained for audit.

Rollback / failure

If form incomplete: complete retrospectively with explanation. If integrity questioned: re-extract with fresh hash; document.

Evidence

Chain of custody form; hash/checksum; transfer log; access log to evidence store.

• 3.5.3 Runbook: Retention Schedule Review
• Element
• Content
• Trigger

Quarterly review cycle; or new log type/system introduced; or change in law or policy affecting retention.

Prerequisites

Current retention schedule; list of log sources/categories; awareness of FOI, DPA, and Electronic Transactions Act requirements.

Steps

1. List all log categories and sources (auth, admin, security, application, operational). 2. For each category, confirm retention (online + archive) is documented and aligned with law and policy; update if law or policy changed. 3. For logs containing personal data, confirm lawful basis and minimum necessary retention; set secure deletion/anonymisation when retention ends. 4. Publish or update retention schedule; communicate to Log/SIEM operators and System Owners. 5. Verify that SIEM and storage configs match schedule (sample check). 6. Document review date and next review.

Validation

Schedule covers all categories; personal data retention justified; config matches schedule for sampled systems.

Rollback / failure

If incorrect deletion discovered: stop further deletion; escalate; document. If schedule gap: add category with interim retention; get Legal/owner sign-off.

Evidence

Updated retention schedule; review record (date, reviewer, changes); sample config verification record.

3.6 Safe Exception Process

Exceptions to mandatory logging or retention requirements 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. Verification and Evidence Baseline (Audit-Ready Logging and Evidence)

To make this standard auditable, ministries and log/SIEM operators SHOULD maintain evidence that, at minimum, demonstrates:

Retention schedule – All log categories with defined retention periods aligned with law and policy; personal data retention justified and deletion/anonymisation scheduled.

Integrity controls – Critical and security logs protected (access control, append-only or integrity mechanism); evidence of configuration and sampling.

Legal hold – Procedure document; legal hold register (active holds, scope, duration, authority); chain of custody forms for extractions.

Exception register – All exceptions to retention or integrity with requirement, justification, compensating controls, owner, expiry, and review date.

Runbook execution – Records of legal hold applications, chain of custody completions, and retention schedule reviews (dates, outcomes).

• What internal audit checks: (1) Retention schedule completeness and alignment with law; (2) sample of systems for correct retention and integrity configuration; (3) exception register for validity and review; (4) legal hold and chain of custody records when applicable.
• Sampling approach: Quarterly sample of log sources per ministry (e.g. 5–10% of critical/high systems); annual full review of retention schedule and exception register.
• Escalation path: Non-compliance identified by audit → System Owner and Security Officer → remediation plan and timeline; repeated or material non-compliance → Document Owner (eGovernment) and senior management.

4.1 Compliance Reporting

5. Legal Compliance and Training

5.1 Legal and Related Standards

Electronic Transactions and Cybersecurity Act (2016): record-keeping, integrity of electronic records.

Data Protection Act (2024): personal data in logs—minimise, protect, retain and delete per policy; lawful basis; secure deletion when retention ends.

• Freedom of Information Act: government records—retention and retrieval within FOI response period where logs are government records.
• Related standards: Malawi Government Monitoring and Observability Guide (what to log, SIEM); Government Server Security Hardening Guide (audit logging, retention minima); Malawi Government Backup and Recovery Guide (archival); Malawi Government Incident Response Guide (evidence preservation).
• Training: System Owners, Security Officers, Legal, and log/SIEM operators on this standard, retention schedule, legal hold, chain of custody, and exception process; 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.16, A.18
• NIST SP 800-53 Rev. 5 – families AU, SI, IR, CP
• Benchmarks – none specific

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

7. Appendices

Appendix A: Related Standards

Malawi Government Monitoring and Observability Guide (`monitoring-observability/monitoring-observability-guide.md`); Government Server Security Hardening Guide (`server-hardening/server-hardening-guide.md`); Malawi Government Backup and Recovery Guide (`backup-recovery/backup-recovery-guide.md`); Malawi Government Incident Response Guide (`incident-response/incident-response-guide.md`).

Appendix B: Control and Legal Mapping

• Appendix C: Evidence and Artifact Checklist
• Retention: Retention schedule covering all log categories; retention aligned with law and policy; personal data retention justified and deletion scheduled.
• Integrity: Access control and integrity mechanism (append-only or verification) for critical/security logs; config and sample verification records.
• Legal hold: Procedure document; legal hold request/approval forms; legal hold register; chain of custody forms for extractions.
• Exceptions: Exception register with requirement, justification, compensating controls, owner, expiry, review date.
• Runbooks: Evidence of retention schedule review, legal hold application, and chain of custody completion where applicable.
• Appendix D: Templates (Minimum)

• The following templates are provided (or referenced) and SHOULD be used as standard formats:
• Legal Hold Request and Approval (D.1)
• Chain of Custody Form (D.2)
• Exception request content requirements (Section 3.6)

D.1 Legal Hold Request and Approval (Template)

• Field
• Description
• Requestor and authority
• Name, role, legal or regulatory authority for hold
• Systems/log categories in scope
• List of systems, applications, or log types to preserve
• Reason
• Litigation / investigation / regulatory (brief description)
• Start date and expected duration/review date
• When hold starts; when to review or release
• Access restrictions and handling rules
• Who may access; how copies are stored and transferred
• Release/closure conditions
• When hold can be released (e.g. matter closed, court order)
• Sign-off
• Legal; System Owner

D.2 Chain of Custody Form (Template)

• Field
• Description
• Evidence identifier and description
• Unique ID; short description of log set
• Source system(s) and collection method
• System names; how collected (export, API, image)
• Collected by (identity), date/time
• Name, role; timestamp
• Hash/checksum (where applicable)
• Integrity hash of extracted dataset
• Storage location and access controls
• Where stored; who has access
• Transfers
• From/to, by whom, date/time for each handover
• Final disposition
• Returned, destroyed, or retained per policy

References

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

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

Freedom of Information Act (Malawi).

Government Server Security Hardening Standards.