# Logging, Monitoring & Retention Policy

**Document owner:** [Owner/Role]  
**Approved by:** [Steering Committee / CISO]  
**Effective date:** [YYYY-MM-DD]  
**Review cadence:** [Annually]

---

## 1. Purpose & Scope
This policy establishes mandatory requirements for security-relevant logging, centralized monitoring, and log retention across [Organization] systems. It applies to all systems that authenticate users, process TLP:AMBER or above data, or sit in the kill-chain tier defined in [Authentication Policy §2.1](authentication_policy.md).

---

## 2. Policy Statements

### 2.1 What Must Be Logged
- Authentication events (success, failure, MFA resets, break-glass invocation).  
- Administrative/privileged actions (permission changes, configuration changes to IdP/PKI/backup systems).  
- Access to TLP:AMBER+STRICT/RED data (per [Data Classification Policy §3.3](data_classification_policy.md)).  
- Secret retrieval events (per [Secrets & Key Management Policy §2.4](secrets_management_policy.md)).  
- System/network security events (firewall denies, IDS/IPS alerts, endpoint detections).

### 2.2 Log Protection
- Logs **must** be shipped to a centralized, access-restricted store (SIEM or equivalent) separate from the systems that generate them.  
- Logs **must** be tamper-evident (append-only/WORM where the platform supports it); local-only logs are not sufficient for kill-chain systems.  
- Access to raw logs **must** follow least privilege (per [Access Control Policy §3.1](access_control_policy.md)).

### 2.3 Retention Periods
| Log Type | Minimum Retention |
|---|---|
| Authentication & MFA events | 1 year |
| Privileged/admin action logs | 2 years |
| Kill-chain system logs (IdP, PKI, backup, break-glass) | 3 years |
| Standard application/security logs | 1 year |
| Network/firewall logs | 90 days online, 1 year archived |

Retention **must not** exceed the schedule defined in the (forthcoming) Data Retention & Disposal Policy for logs containing personal data.

### 2.4 Monitoring & Alerting
- Real-time alerting **must** be configured for: break-glass checkout, kill-chain system access, MFA resets, and privileged role changes.  
- Alert thresholds **must** be reviewed at least annually to reduce false-positive fatigue without silencing genuine signal.

### 2.5 Log Review Cadence
- Automated alerting is primary; manual review of aggregate trends **must** occur at least monthly for kill-chain systems.

### 2.6 Enforcement
- Systems that cannot ship logs to the central store **must** be remediated or formally excepted with CISO approval and a compensating control.

---

## 3. Antifragility Alignment
This policy is built to the five pillars of the organization's internal **Antifragile Enterprise Manifest**.

| Pillar | Applied In | How |
|---|---|---|
| **1. Structural Decoupling** | §2.2 | Logs shipped off-system to a store independent of the generating platform — a compromised host can't erase its own evidence |
| **2. Optionality Preservation** | §2.2 | Centralized store in standard formats avoids lock-in to one SIEM vendor's proprietary log format |
| **3. Stress-to-Signal Conversion** | §2.1, §2.4 | Instrumenting kill-chain and privileged events is the raw material for the structural post-mortems required in [Authentication Policy §2.12](authentication_policy.md) |
| **4. Sovereign Intelligence** | §2.5 | Log review findings are tracked and owned, not left as raw data no one reads |
| **5. Asymmetric Payoff Design (Barbell)** | §2.3 | 3-year retention and real-time alerting concentrated on kill-chain systems; standard logs get the lean 1-year baseline |

---

## 4. References
- **[NIST SP 800-92, Guide to Computer Security Log Management](https://csrc.nist.gov/pubs/sp/800/92/final)**  
- **[CIS Controls v8.1 (Control 8)](https://www.cisecurity.org/controls/v8-1)**  
- **[ISO/IEC 27001:2022](https://www.iso.org/standard/27001)**