> For the complete documentation index, see [llms.txt](https://docs.softwaresecured.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.softwaresecured.com/planning/preparing-your-environment-for-the-testing-team.md).

# Preparing your environment for the testing team

When preparing an environment for the penetration test, ensure that it mirrors your production environment as closely as possible and accurately represents normal operating conditions for a typical user or customer. 

***

### **Test environment requirements**

The following requirements help <code class="expression">space.vars.company\_name</code> ensure the best possible coverage of the test:&#x20;

* All features that are used for the most common use cases or workflows are fully enabled, configured, and licensed on the environment.
* All known differences between the test and production environment are highlighted during the kickoff call.&#x20;
* If the system has known integrations with other external systems, <code class="expression">space.vars.company\_name</code> might need access or testing equivalents of those to ensure that we can test for any risks posed by the integration points and any associated data flows into the system.
* If a web application firewall (WAF), intrusion prevention system (IPS), or other security appliance is in use, they either need to be disabled, or the IP addresses of the testers need to be given access permission through your network's allowlist (or whitelist).
  * <code class="expression">space.vars.company\_name</code>’s IP addresses are included in the pentest checklist. For more information, see [Pentest checklist](/checklist/pentest-checklist.md).&#x20;
* The test environment must be consistently available throughout the test dates until final report delivery. This access supports the report writing, evidence collection, and our quality assurance process. Once the report is delivered, the environment can be de-provisioned if needed.&#x20;
  * Alternatively, in packages with frequent pentesting operations like [Penetration Testing as a Service (PTaaS)](https://www.softwaresecured.com/service/penetration-testing-as-a-service), the environment is kept live to facilitate faster retesting and consultation requests.

These requirements help <code class="expression">space.vars.company\_name</code> ensure the best possible coverage of the test.&#x20;

{% hint style="info" %}
If you wish to test the effectiveness of these controls, ask us about other test offerings such as [red teaming](https://www.softwaresecured.com/service/red-teaming) and [cloud security reviews](https://www.softwaresecured.com/service/secure-cloud-review).&#x20;
{% endhint %}

***

### Testing the production environment

Any network or infrastructure pentests are conducted on the production environment.&#x20;

For all other test portions—such as application or software— <code class="expression">space.vars.company\_name</code>'s best practice is to test on a staging or a test environment.&#x20;

Pentesting an application in a production environment is possible; however, pentesting by design is an invasive process and tests come with risks for outages or data deletion. When focusing solely on the network, these risks are less of a concern compared to when data or availability can be compromised.&#x20;

{% hint style="warning" %}
When testing on production is required, complete a backup before the start of testing—and at regular intervals throughout the test—to ensure business continuity if any outages occur.
{% endhint %}

For more information about the advantages and disadvantages of testing on production, see [15 Risks & Rewards of Pentesting in a Production Environment](https://www.softwaresecured.com/post/pentesting-in-a-production-environment).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.softwaresecured.com/planning/preparing-your-environment-for-the-testing-team.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.