Banner image of 3 Don'ts of penetration testing and security assessments

3 Don'ts of penetration testing and security assessments

Penetration testing can be used to systematically find security vulnerabilities and discover security risks. However, if done wrong, penetration testing results in a list of arbitrary problems that aren’t necessarily related to security.

In this article, we show three things good penetration testers don’t do.

Always stay in the loop!
Subscribe to our RSS/Atom feeds.

The goal of penetration testing

The primary goal of most penetration tests is to get a list of verified security vulnerabilities and their risks for the tested environment.

A penetration tester works within a predefined scope, so a single penetration test commonly doesn’t cover every single possibility to penetrate a system. There are different testing concepts (white-box testing, gray-box testing, black-box testing), and perspectives (external attacker, internal attacker). Therefore, two penetration tests covering the same system can discover totally different risks.

Actions that should be avoided

In the following, we list three actions an experienced penetration tester should avoid.

Action 1: Don’t test anything without permission

You should never start testing without permission of the system owner. In many countries, penetration testing without permission will be likely considered illegal, so your actions may result in legal consequences.

There is also the danger of breaking something or triggering intrusion detection/prevention systems. This can result in damage or wrong testing results.

Thus, get a written permission of the system owner before you start. Know the target environment, and stay within the predefined scope of the test. One exception: Organizations may allow penetration testing without prior permission in some cases. Look for a security/disclosure policy. Some organizations even have a bug bounty program.

Action 2: Don’t be a script kiddie

Running arbitrary scripts and tools while hoping to find something is actually very unprofessional. The (inexperienced) customer hired you to work professionally. Actually, running tools without knowing their functionality can result in damage of some kind: Your script could delete or modify files, or the targeted system can’t process requests by the script and crashes.

Therefore, know your scripts and tools. Understand how they work and what they do. Understand their limitations. For instance, some online assessment tools like Webbkoll, Qualys SSL Labs, the Mozilla Observatory can only test a very small fraction of security-relevant configuration as explained in “Limits of Webbkoll” and “Pros and cons of online assessment tools for web server security”, or they show totally wrong results.

Action 3: Don’t report something without verifying it

Finally, don’t write something in your report that you didn’t verify. Compiling a list of 50 unconfirmed findings, which could—in theory—be exploited, doesn’t help your customer in any way. For example, a penetration tester without any OT experience may come to wrong conclusions since most IT security vulnerabilities won’t be exploitable in OT environments or they are irrelevant to the customer.

The same is true for the above-mentioned online assessment tools: If you run these tools, keep in mind that most findings aren’t confirmed or may be irrelevant due to the environment of the system. Therefore, verify findings and consider the environment of the tested system.

And please, if you find something really bad, responsibly contact the owner of a system. Don’t publish any “Attention please, I discovered lots of security vulnerabilities”-style blog posts based on unconfirmed assumptions. This not only looks unprofessional, but it can also damage your reputation.

Follow us on Mastodon:


In the end, a good penetration test needs an experienced penetration tester, a systematic process, the right tools, and reporting skills. Get a written permission, stay within the predefined scope, know your tools, and be confident when writing the report afterward.

Read also