System operations and monitoring
System operations and monitoring require the organization to implement processes that detect anomalies, security threats, and operational failures in real-time or near real-time. The goal is to ensure that any deviation from expected performance or security baselines is identified and remediated promptly to maintain system availability and security.
What it means
In practice, this control focuses on visibility. It requires you to move beyond simply having a functioning system to having a way to prove the system is behaving as intended. This involves monitoring both the infrastructure (uptime, resource utilization) and the application layer (error rates, unauthorized access attempts).
The scope includes vulnerability management—identifying weaknesses before they are exploited—and incident detection—identifying when an exploit or failure has occurred. It essentially mandates a closed-loop process: you must define what "normal" looks like, detect when things become "abnormal," alert the right people, and document the resolution.
How to meet it
- Implement centralized logging for all critical systems, ensuring logs capture authentication events, administrative changes, and system errors.
- Configure automated alerting for high-severity events (e.g., server downtime, repeated failed logins) that notify a designated on-call engineer or security team.
- Establish a regular vulnerability scanning cadence (weekly or monthly) to identify unpatched software or misconfigurations in your environment.
- Define and document an Incident Response Plan that outlines the steps for detection, containment, eradication, and recovery.
- Deploy system health monitoring tools to track key performance indicators such as CPU usage, memory exhaustion, and disk space.
- Create a process for reviewing security logs or audit trails on a periodic basis to identify patterns that automated alerts might miss.
Evidence an auditor asks for
- Screenshots of active monitoring dashboards and configured alert rules showing the trigger conditions and notification recipients.
- Recent vulnerability scan reports paired with evidence (tickets or pull requests) showing that identified high-risk vulnerabilities were patched.
- A sample of incident tickets demonstrating a full lifecycle: from the initial automated alert to the final resolution and root cause analysis.
- The formal Incident Response Policy and any records of annual tests or "tabletop" exercises performed to validate the plan.
- Sample log exports showing that critical system events are being captured with accurate timestamps and user identifiers.
Common pitfalls
- Alert Fatigue: Setting too many low-priority alerts, leading staff to ignore notifications; auditors look for evidence that alerts are actually acted upon.
- Scanning without Remediation: Running vulnerability scans but failing to document the fixing of those vulnerabilities, which proves the monitoring is useless.
- Lack of Log Integrity: Storing logs locally on servers where an attacker could delete them, rather than shipping them to a secure, centralized location.