Penetration testing is most effective when scope, intent, and execution are aligned.
Most issues customers encounter are not caused by the testing itself, but by small missteps during setup or execution. This article highlights the most common mistakes teams make when running tests in RedVeil and how to avoid them.
Avoiding these pitfalls helps ensure testing runs smoothly and delivers meaningful results.
Testing the Wrong Environment
One of the most common mistakes is testing the wrong environment.
This often happens when similar domains, IPs, or URLs exist across production, staging, and development. Accidentally testing a non-production environment can lead to misleading results, while unintentionally testing production without preparation can cause unnecessary concern.
Before starting a test, take a moment to confirm:
The environment matches your intent
The project name clearly reflects what is being tested
Scope entries point to the correct assets
Clear project naming and careful scope review during the Review step help prevent this mistake.
Misconfigured or Incomplete Targets
Another frequent issue is misconfigured scope.
This can include missing subdomains, incorrect URLs, unreachable IPs, or providing large CIDR ranges without understanding what is actually live. When scope is incomplete or incorrect, testing may appear to finish quickly or produce fewer findings than expected.
If a test yields no results or fails unexpectedly, it’s often worth confirming that:
Targets are reachable from the internet
Security controls are not blocking all interaction
Authentication credentials were valid and the appropriate authentication method was used
Testing is designed to evaluate hosts and applications - not firewalls or security controls. Leave that part to the red team operations!
Canceling Tests Too Early
While stopping a test is always safe, canceling before testing has progressed meaningfully can prevent findings from being fully validated or documented. This may result in lost context or the inability to generate reports and can be quite frustrating when a test has been running for some time.
If a test appears quiet or slow, it’s often still performing discovery or validation. Rune can help explain what stage the test is in and whether waiting is appropriate.
Canceling makes the most sense when scope or configuration is incorrect, not simply because results are not immediate.
Running Overlapping Tests Without Coordination
In team environments, multiple users may start tests at the same time without realizing it.
Because tests consume Agent Ops, overlapping execution can significantly increase usage and reduce available capacity unexpectedly. This is especially common in shared accounts without clear communication and can lead to a situation where more Agent Ops need to be purchased to perform future testing against other targets due to redundant testing being performed by users.
Coordinating test execution internally helps ensure Agent Ops are used intentionally and aligned with priorities.
Expecting Identical Results Every Time
Penetration testing is not a checklist audit.
Different tests against the same scope may produce different results due to changes in the environment, application behavior, time constraints, or attack paths explored. This variability reflects realistic testing, not inconsistency.
If validating a specific fix, using RedVeil's One-Click Retest feature is often more appropriate than expecting a full test to reproduce identical findings.
Ignoring Scope Size and Complexity
Very large scopes can dilute testing effectiveness if not planned carefully.
Attempting to test many web applications or large network ranges in a single test can increase duration and complexity unnecessarily. Breaking large scopes into smaller, focused tests often produces clearer results and easier remediation.
In these situations, RedVeil recommends:
Instead of a large CIDR range, consider providing only known live host IPs to ensure efficient testing is being conducted
For web applications, ensure that subdomains for a web application are unique in function if listing them for individual testing and aren't the same application with slightly different functionality
i.e. www.example.com and secure.example.com
(These two would be counted as separate web applications with separate levels of effort in the form of Agent Ops)
For authenticated testing, we recommend providing the most common standard user account and not an elevated super-user