Network Security Testing

Network security testing checks whether the networks that connect a firm's systems, people, and suppliers actually enforce the boundaries the firm believes they enforce. It looks for paths that should not exist, segments that should be isolated but are not, and access routes that are wider than intended. A network diagram may show a tidy separation between a trading platform, a back office system, and the internet. Testing asks whether traffic can in fact move between them, whether a compromised workstation can reach a critical database, and whether a supplier connection can be used to reach more than the service it supports. Under DORA, this is part of the basic testing layer for systems supporting critical functions, and its value lies in surprises.

Testing covers the design and the reality of the network. Design questions concern segmentation, such as whether payment processing sits apart from general office systems, and whether administrative access follows a separate, more controlled path. Reality questions concern what is actually configured: firewall rules accumulated over time, legacy connections nobody remembers authorising, remote access for support staff, and links to cloud services and suppliers. A branch network example illustrates the point. A branch terminal should reach only the services it needs, and a failure or compromise at one branch should not become a route into central systems. Testing verifies that, rather than assuming the diagram is the network.

Supplier connections are often the most consequential network paths and the least examined. A market data feed, a hosted platform, or a support connection may be granted broad access when it was set up, then never narrowed as the service changed. Network testing should therefore include those connections explicitly: what can the supplier reach, from where, with what credentials, and what happens if the supplier's own environment is compromised. A firm that tests only its internal network while leaving supplier paths untested has examined the house while leaving a side gate unlatched. The guide on third party risk in the wider site, and the testing findings guide in this cluster, both connect to this point.

Network testing ranges from reviewing configurations and firewall rules to actively probing whether a path can be traversed, using techniques agreed in advance and bounded to avoid harming live services. The realism pitfall matters here too. Probing a test network that mirrors production only in outline may miss the rule that was added directly in production during an incident and never documented. Testing should therefore be scoped to production configurations wherever that can be done safely, and where it cannot, the gap between test and production should be stated. A finding that a test network is secure, while production differs, should be reported with that qualification attached.

Network test results are most useful when they describe paths, not just vulnerabilities. A report that says a segment can be reached from an unexpected source, with the steps taken and the data that could then be accessed, gives the owning team something concrete to fix. A report that lists generic weaknesses with no path attached is harder to act on. Prioritisation should follow the critical function. A path into a system that processes customer payments outranks a path into a low sensitivity internal tool, even if the technical flaw looks similar. That judgement, recorded alongside the finding, is what connects network testing to the resilience of a named service.

Findings feed the same loop as other testing in this cluster: owner, remediation or a documented acceptance, and retesting to confirm the path is closed. Network changes made in response should themselves be checked, because a rule added hastily to close one path can open another or break a legitimate service. Over time, repeated testing builds a picture of drift, as rules accumulate and connections multiply. A firm that can show that picture, with paths closed and retested, has evidence of control. A firm that can only show that a test took place, with no path described and no closure recorded, has evidence of activity only.