A slow network is not, by itself, evidence of a cyberattack. It can still matter to security and operations because people depend on connectivity to use services, receive alerts and coordinate a response. Performance, availability and security should be examined together when a degradation affects important systems, but teams should diagnose the cause rather than assume one.
Availability belongs in the security conversation
NIST’s Cybersecurity Framework 2.0 includes technology infrastructure resilience and maintaining sufficient resource capacity to support availability among its outcomes.^1 This does not make every latency problem a security incident. It does recognise that organisations need infrastructure that can protect availability as part of their broader risk strategy.
Network conditions can affect whether users reach applications, whether monitoring data arrives consistently and whether teams can use the tools they need during an event. A service may also be slow because of an application, DNS, identity, a cloud dependency, a device or a carrier path. Treat the symptom as a starting point for investigation.
Establish a useful baseline
Record performance measures that relate to the services users depend on. Depending on the environment, this may include latency, packet loss, jitter, availability, interface errors, wireless coverage, DNS response and application response time. Define where each measure is collected and what normal variation looks like across sites and times of day.
A single average can hide problems. Compare the affected users and locations with a reference group, and check whether the issue occurs on one network path, one application or multiple services. Note when the degradation began and whether it followed a change, a traffic spike or an external event.
Use measures that help distinguish a user experience problem from a network transport problem. If users report slow access to one application while other services perform normally, investigate that application’s dependency chain before changing network capacity.
Join infrastructure and security evidence
During an investigation, compare network observations with security events, identity activity, endpoint alerts, application logs and cloud-service status. Look for timing and scope, not just a shared symptom. An increase in traffic, a policy change or a device issue may be relevant, but correlation alone does not prove cause.
Make sure security tools and monitoring services have the connectivity and configuration they need to collect useful data. Check whether there are blind spots, dropped logs or unreachable management interfaces. If a system is degraded, state which data sources are affected so responders know what the evidence can and cannot show.
Plan escalation across teams
Network, security, cloud and application teams may own different parts of the same service. Agree who coordinates a cross-team incident, who can approve a change and how the impact is communicated. Keep a shared record of the symptom, affected users, tests performed, evidence collected and next action.
If the issue affects a critical service, use the agreed severity and escalation process. Avoid making unplanned changes that could remove evidence or expand the outage. If an immediate containment action is needed, record who authorised it and what monitoring should confirm afterward.
Treat capacity as one hypothesis
Adding bandwidth may help when a link is saturated, but it will not fix every cause of slowness. Check interface utilisation, congestion, loss, path quality, DNS, application health and the end-user device. Consider whether traffic patterns or new workloads have changed since the network was designed.
If capacity is constrained, identify the affected links and applications, estimate the operating requirement and decide whether to optimise, prioritise, redesign or increase capacity. Validate the result after the change rather than assuming the intervention worked.
Test availability and recovery
For important network paths, identify the single points of failure and confirm what happens when a component or circuit fails. Check whether a secondary path is independent, how failover is triggered, what services remain reachable and who receives the alert. A diagram showing two links is not enough if both depend on the same conduit, provider or power source.
NIST’s framework describes resilience as part of the security architecture and risk strategy. Use that as a reason to include availability in reviews and exercises, while adapting specific measures to the organisation’s environment.^1
Improve the joint view
Track recurring issues across infrastructure and security operations. Review the quality of monitoring, the accuracy of dependencies, the clarity of escalation and whether changes reduced the observed problem. Separate confirmed cause from working hypothesis in incident notes.
Read how to investigate DNS-related slowness and how to plan resilience beyond one link. For AltTab’s current network assessment and connectivity scope, see Networking and connectivity.