Penetration testing is designed to surface security weaknesses by behaving like a real attacker. That inherently means interacting with systems in ways they were not originally designed for.
RedVeil is built to perform testing responsibly, but successful testing also depends on how customers prepare, scope, and coordinate internally. This article outlines when testing production systems is appropriate, when non-production environments are a better choice, and what precautions help minimize unintended impact.
Testing Production vs. Non-Production Environments
Testing production systems is common and often appropriate, especially when the goal is to understand real-world exposure.
Production testing makes sense when:
The system is stable and well-monitored
You want to assess actual external risk
Findings need to reflect real customer-facing behavior
However, non-production environments can be a better choice in some situations. Testing staging or pre-production environments may be preferable when:
Significant changes are actively being deployed
The application is fragile or untested
You want to experiment with deeper testing configurations
Business impact tolerance is low
Both approaches are valid. The key is choosing intentionally based on risk tolerance and testing goals. If you are testing for compliance, make sure you consult with your auditor about their expectations for your testing to meet the requirements of the compliance framework.
Understanding Realistic Risk During Testing
Penetration testing is not the same as vulnerability scanning.
Testing involves logic evaluation, state changes, and interaction patterns that may trigger edge cases while simulating a threat actor. While RedVeil is designed to be rate-limited and cautious, no penetration testing can guarantee zero impact whether it's by a human or automation.
This does not mean testing is unsafe - it means testing should be planned. Most issues during testing are not caused by exploitation itself, but by assumptions about environment readiness or lack of internal coordination. Organization's will also quickly find out which vendor tools may not be tuned appropriately when alert emails come flying in by the dozens.
Recommended Precautions Before Testing
A few simple precautions dramatically reduce risk.
Before starting a test, it’s a good practice to ensure monitoring is active, logs are available, and on-call teams are aware that testing will occur. This avoids unnecessary alarm and helps distinguish testing behavior from real incidents.
For authenticated testing, use accounts with appropriate permissions rather than highly privileged administrative users unless explicitly required. This reduces unintended side effects while still providing meaningful coverage.
If testing sensitive workflows, consider starting with a smaller scope and expanding once confidence is established.
If an organization has never performed a penetration test, the most beneficial testing type that can be performed is white-box testing. This type of testing helps identify exploitable vulnerabilities directly on targets without security controls in place by whitelisting the penetration tester's activity.
Internal Authorization and Approvals
Penetration testing should never be a surprise.
Ensure that testing has been approved internally by the appropriate stakeholders. This may include security leadership, infrastructure teams, application owners, or operations teams depending on your organization.
RedVeil will only test assets explicitly placed in scope, but internal alignment is still critical.
When to Pause or Adjust Testing
If unexpected behavior is observed during testing, it is always acceptable to stop a test.
Stopping early is often preferable to letting a test continue if something feels off. Adjustments can be made and testing resumed later with a new test once concerns are addressed.
Rune can help interpret what is happening and whether changes are needed before continuing.