Controls Matrix by Risk Level - Monitoring and Operations
This matrix defines the minimum mandatory monitoring requirements for applications, according to their risk level (L1 to L3). It serves as the basis for compliance assessment and for the planning of controls throughout the lifecycle.
⚠️ This matrix applies to applications classified according to the risk model of Chapter 1.
📊 Coverage matrix
| Control / Requirement | L1 | L2 | L3 |
|---|---|---|---|
| Structured and persistent logging | ✔️ | ✔️ | ✔️ |
| Critical events defined (login, error, etc.) | ✔️ | ✔️ | ✔️ |
| Minimum retention in line with Policy 29 (security logs: 90 days L1, 1 year L2, 2 years L3) | ✔️ | ✔️ | ✔️ |
| Logs sent to a centralised system (SIEM) | ✔️ | ✔️ | |
| Automatic alerts configured | ✔️ | ✔️ | |
| Trigger simulations tested | ✔️ | ✔️ | |
| Correlation between sources | ✔️ | ||
| Behavioural detection / adaptive profiles | ✔️ | ||
| Integration with incident response (IRP) | ✔️ | ✔️ | |
| MTTD / MTTR metrics monitored | ✔️ | ||
| Continuous operational health/readiness signal for critical services | ✔️ | ✔️ |
✅ Interpretation
- ✔️ = mandatory for that level
- L1: local and basic logging for traceability
- L2: centralisation of events, fundamental operational alerts and a continuous health signal for critical services
- L3: contextual detection, correlation, integrated response and full coverage of operational health/readiness signals
🥉 This matrix must be cross-referenced with the requirements catalogue (Ch. 2) and the maturity criteria (
addon/achievable-maturity).
📌 Additional recommendations
- Applications with external exposure and sensitive data must, even when L1, meet L2 or L3 requirements;
- Use this matrix as the basis for review in architecture, design and production readiness;
- Include these requirements in the definition of "Done" and in the acceptance criteria of releases.
🔒 The matrix works as a reference for minimum control, not as a ceiling on ambition. Mature projects must go further.