The decision on which environment to use for Penetration Testing ultimately comes down to your risk appetite as a company. Typically, there are three main types of environments that we encounter in security consultancy: development, staging and production. These three can all have penetration testing performed against them; however, they all have different risk/reward ratios and considerations which may make them more or less suitable in your specific circumstance.
Testing in the production environment will provide the most representative results. Unlike development, for example, production will be using all of the configuration, middleware and resources that the customers and stakeholders will be using, as it is the final live environment. This means any finding that is discovered will be applicable and will likely impact all live users of the application of a similar role to the testing account at the current time. Production, for this reason, is often the first choice of many organisations for the environment to test, as there is little to no investigation needed to determine whether a finding is applicable and remediation required.
However, production also carries the most risk for penetration testing activities. Oxford Systems will never intentionally attempt to cause disruption; however, penetration testing by its nature is a somewhat destructive exercise. Many types of web application attack involve the manipulation or corruption of data which, in certain situations, can sometimes be displayed site-wide. While uncommon, this can also introduce system instability which could cause disruption to end users currently utilising the application. Penetration testing firms are no strangers to this and often will use less invasive methods to assess the application in production to avoid disruption. However, these less invasive methods can also reduce the accuracy of work and introduce the potential for false negatives, which is not advisable. For many companies, production systems will be handling critically important live data for end users, and it is for this reason that testing in production should be considered very carefully.
Staging is the environment used to carry out unit testing and quality assurance prior to any pushes into production. For this reason, staging will typically be mostly representative of production and often reflects similar resources and middleware to make unit testing as applicable as possible. Staging often will have some form of test data already ingested, which makes it fairly straightforward for penetration testing purposes. This environment carries a lot less risk, as any unfortunate disruption or corruption of data should not extend into production and therefore should only impact users of the staging environment. This environment will also often see deployments and rollbacks, and therefore have strong processes in place to reset if needed. It is due to the lower risk and the high representation that staging often provides the best risk/reward ratio of all environments for penetration testing purposes. Of course, this does depend on the purpose of the test and organisation specifics, though.
The development environment carries almost no risk, as data corruption and disruption will be very common and there will be processes in place to perform regular resets. While the risk is low, this is also true of reward, as the environment will typically not be representative of production. Findings on a codebase level therefore will likely be applicable, but any findings to do with middleware or specific environmental configuration may not carry true in production or staging. Therefore, more work is required on the customer’s side to determine whether findings are truly applicable or not. Additionally, the resets and code changes that will be happening regularly as part of the development process can make this environment somewhat unstable and can introduce false positives and negatives into testing results. Lastly, resources for development environments are typically a lot less than for staging or production, which increases the possibility of accidental denial-of-service through resource consumption. Denial-of-service attacks are never performed intentionally in any environment unless explicitly requested, but testing activities can strain systems with low resources and cause system instability due to the high number of requests and processing power required to process those requests.
Which environment to perform testing in ultimately depends on your organisation’s risk appetite and the level of representation to production you require the results to have. In many situations, staging provides a good middle ground. However, the answer will ultimately depend on the specific goals you are looking to achieve with the penetration test and how much risk the organisation is willing to accept to achieve them.
© 2025 | Oxford Systems
5 Minton Place, Victoria Road, Bicester, Oxfordshire, OX26 6QB, United Kingdom
cyber@oxfordsystems.co.uk