Which systems should remote monitoring cover?

Remote monitoring should cover any technology whose failure, degradation or compromise could interrupt operations, prevent access to essential information, or weaken the organisation’s ability to recover. The right scope is therefore based on business dependencies rather than a simple inventory of every connected device.

Start with business-critical services. Identify the applications and processes that staff rely on to take orders, communicate, manage accounts, handle production, deliver services or access shared information. Then trace the technology supporting each process. This dependency-based approach helps reveal systems that may appear minor but are essential, such as a directory service used for authentication, a virtual host supporting several applications, or a connectivity device linking a remote site to central resources.

User devices should be covered according to their role and risk. Monitoring can include device availability, operating system health, disk capacity, patch status, encryption state, security-agent status and signs of hardware or performance problems. Monitoring every personal setting is not necessary. The useful scope focuses on conditions that could affect business access, expose information or indicate that a device needs investigation.

Servers require checks that reflect the services they provide. Basic availability checks are only the starting point. A suitable configuration may monitor processor and memory pressure, storage capacity, critical services, failed jobs, event-log conditions, certificate expiry and the health of virtual machines or hosts. A server can remain powered on while an important application, database connection or scheduled process has stopped, so checks should test service function where this is technically possible.

Network infrastructure should be monitored at each important connection point. This may include internet links, routers, firewalls, switches, wireless infrastructure, site-to-site connections and remote-access gateways. Monitoring should distinguish between a complete outage, high latency, packet loss, a failing component and a local wireless issue. That distinction gives support teams more useful evidence when investigating whether the cause is inside the organisation, at a service provider or at a particular site.

Cloud services need a different approach from on-site equipment. Monitoring may focus on identity and authentication, synchronisation, service connectivity, usage limits, configuration changes, certificates, failed integrations and the availability of important workloads. Where the provider controls the underlying platform, the organisation may not be able to inspect every technical layer. Monitoring should therefore concentrate on the parts it controls, the user-facing service and the connections between cloud platforms and internal systems.

Backups should be monitored as recovery systems, not merely as scheduled tasks. Useful checks include job completion, failed or incomplete jobs, storage capacity, age of the latest usable recovery point, unusual changes in backup volume and the status of replication where applicable. A successful job message does not by itself prove that the required data can be restored, so backup monitoring should sit alongside planned restoration checks and documented recovery priorities.

Security-related controls should be included where their status affects risk. Examples include endpoint protection, patch compliance, encryption, privileged-account activity, firewall configuration and indicators that a security control has been disabled. These checks should be connected to an investigation process rather than treated as a substitute for wider security measures. Monitoring can identify a missing update or inactive protection agent, but it does not remove the need for secure configuration, access controls, user awareness and incident procedures.

Include specialist and operational technology when it supports a business process. Manufacturing equipment, warehouse systems, telephony, payment services, access-control systems, environmental monitoring and other connected devices may need coverage if their failure affects production, safety, logistics or customer service. The monitoring method must suit the system. Some equipment may support basic availability or capacity checks but should not be changed, scanned or restarted without approval from the responsible supplier or system owner.

Use monitoring tiers instead of applying identical checks everywhere.

• Priority systems: monitor availability, service health, capacity, security status and dependencies closely enough to support prompt investigation.
• Important systems: monitor the conditions most likely to cause disruption, such as storage limits, failed services, connectivity loss or outdated protection.
• Supporting or low-risk assets: monitor basic reachability and health, with deeper checks added if their business role changes.
• Excluded assets: document devices that cannot be monitored safely, are outside organisational control or do not justify the technical and privacy implications of monitoring.

The scope should also account for ownership. Internally managed equipment can usually support more detailed checks than a third-party platform or supplier-managed device. For outsourced services, define which party monitors the underlying system, which party verifies the service from the organisation’s perspective and how relevant information is shared during an investigation.

Finally, review coverage whenever the organisation introduces a new site, application, cloud workload, network connection or recovery arrangement. A system should be added when it becomes a dependency, and checks should be removed or revised when an asset is retired or its role changes. This keeps remote monitoring aligned with the current technology environment rather than leaving gaps or retaining checks that no longer provide useful information.