Nederlands
Pentests are preferably conducted on an acceptance or test environment rather than on production. This protects your business operations while enabling more thorough testing. This page describes why, what makes a suitable test environment, and what to do if you don't have one.
Five reasons to pentest on the acceptance or test environment
1. Protecting production systems
Pentests use techniques that can strain live systems. A SQL injection test that creates thousands of test records, an automated scan that triggers rate limits, or a payload that crashes an application: on acceptance this is resolvable, on production it leads to downtime and customer impact.
2. Protecting data integrity and customer data
During a pentest, data can be modified, added or deleted. On acceptance we work with test data. On production this would mean real customer data is disrupted, which alongside operational impact also has GDPR implications (integrity principle).
3. Avoiding unintended side effects
A test can trigger unintended actions: emails to real customers, payments via payment gateway, orders in external systems, or workflows being activated. On acceptance these integrations are mocked or connected to sandbox environments; on production real transactions would occur.
4. Compliance and accountability
Compliance frameworks such as ISO 27001, NIS2 and NEN 7510 recommend or require that security testing takes place in a non-production environment to avoid impact on business operations and sensitive data. For DigiD assessments this is part of the framework.
5. Efficient remediation cycle
Findings can be resolved and retested on acceptance before being deployed to production. Your development team can create patches, retest and then deploy. This is the usual DevOps workflow and fits logically with pentesting.
What makes a good acceptance environment for a pentest
Not every acceptance environment is immediately suitable. For an effective pentest your acceptance environment should:
- Have recent production code. Ideally deployed from the same branch as production or from a release branch.
- Have all functionality working. Disabled features create blind spots.
- Contain test data. Anonymized or dummy data covering all scenarios (different user roles, edge cases, multi-tenant).
- Have comparable configuration. Same security settings, same headers, same authentication flow as production.
- Use SSL/HTTPS. Certificates can be self-signed or Let's Encrypt-based, but HTTPS is required to test realistic scenarios.
- Have working integrations. External API integrations connected to sandbox environments of the respective party (for example iDEAL test endpoint).
- Have backups. Full backup before the pentest starts, so you can recover from unexpected issues.
What if you don't have an acceptance environment
For smaller organizations or older applications, an acceptance environment is not always available. We then discuss the following options with you:
- Set up a temporary staging environment. For the duration of the pentest, with a copy of production. We can advise on minimal configuration.
- Controlled production testing. Under strict conditions and with limited scope: no destructive tests, read-only operations, and test window outside peak moments. Only suitable for low-risk applications.
- Read-only production assessment. Passive inventory without active exploitation. Finds configuration errors and known vulnerabilities, but no business logic flaws.
- Postpone the pentest. First invest in setting up an acceptance environment. We can advise on the minimum requirements for pentest purposes.
The right option depends on your compliance requirements, risk tolerance and available resources. This is discussed during the scoping conversation.
Want to learn more about preparing for a pentest? See the FAQ on how you prepare for a pentest. Contact us for a complimentary scoping conversation, or view our pentest packages.