The need for and extent of system monitoring follow from the business risk and the risk to patients, product quality and the integrity of data, judged against what kind of system it is and how exposed it is externally; monitoring may cover a system, a group of systems or an infrastructure environment and reports on failures, availability, performance, drift from the configuration baseline and security problems, feeding incident and problem management and improving controls. The system owner ensures risk-based monitoring is in place with administrators and IT and participates in handling detected incidents, and the process and data owners agree the scope and participate. Considerations include system and data availability, performance and resources, network routing, loading and outages, configuration compared with templates, batch job failures including backups, communication faults on interfaces and instruments, faults in software, operating system and hardware, printer queues, alarms and events, security vulnerabilities and intrusion detection. Automated tools are used wherever possible to detect, alert and, where available, self-rectify by adjusting resources or resetting configuration to the template, and manual monitoring tasks are defined and scheduled in service management tools or administration plans with tasks, roles, frequency and reporting stated.
This control maps to 1 controls across 1 other frameworks. If you already hold one of them, the evidence you collected for it is the starting point here rather than new work.
Every mapping shown was judged rather than inferred from wording similarity, and the ones that failed review are published too. See the coverage reports and what was rejected.
The graph holds this control, the 1 it maps to, and the evidence behind each claim, over MCP and REST.