Knowledge Center

What happens if we experience application or network issues during pentesting?

Production Issues

This question comes up, in one form or another, almost every week. Will my network go down? Is the testing going to break my application? What if I start getting strange alerts, or see weird behavior?

This is even more of a concern when tests are being done against live production systems. As an administrator, these systems are your babies. You’ve spent countless hours setting them up, tweaking configuration settings, interfacing with other new and/or old systems, troubleshooting 'that one user’s mysteriously intermittent issue', checking system event logs, and the list goes on. Therefore, it's only natural that there should be some apprehension when intentionally allowing someone to pentest your system.

While it's easy to assume the worst, the reality of the situation is that destroying a system or network doesn't happen as often as one might think. That's not to say that unexpected results don't occur, but a responsible pentester is careful with the tools they run, and the activities they perform. For example, most pentesters do not intentionally create a Denial of Service (DoS) condition, or trigger a cascading event that disrupts business operations.

So, the question of, "What do I do if my systems go down during a pentest?", should be a fairly straightforward answer. You would follow your normal procedures when dealing with an irregular system or network event. However, if you or your upper management know that pentesters are engaged in testing that week, then there's a few other things that should also be considered.

First, clear lines of communication and point-of-contact information (in the event that something critical happens) should be established before the test ever begins. This allows for informed, quick responses if something is ever a concern during the test. Second, if a critical or otherwise concerning issue arises over the course of a pentest, then you should reach out to your testers sooner rather than later. This actually accomplishes two main purposes:

  1. If a scan, tool, or some other pentesting activity, is actually causing the problem, then it can be halted quickly, giving you time to work with your tester. This is the point where you can work together to figure out what the issue is, why it's happening, and collaborate on a way to move forward in a way that's in-line with your testing goals and business policies.

  2. If the pentest isn't the cause of the issue, then it may still be beneficial to halt testing temporarily, removing that activity from the equation, which makes things easier for the administrators who are troubleshooting the problem internally.

Hopefully you don’t have to troubleshoot any serious issues while a pentest is being conducted across your network or on your application. However, if it does happen, then approach the problem logically, just as you would any other event, and don’t hesitate to communicate with your pentesters so that you can both narrow down the problem faster, and eliminate any anomalies that may be caused by the test itself.

If you are interested in a breakdown of some other types of potential risks when getting a pentest, then you can visit this article, What are the risks of a penetration test. We also answer other types of questions in our Knowledge Center. Finally, if you’re looking for a penetration test, training for your organization, or just have general security questions please Contact Us.

Back to the

Knowledge Center

Didn't answer

your question?