How to prepare for a penetration test: what should the client do?

The client has three jobs: describe in writing what exactly will be tested, sign a permission with rules for the work, and prepare access, people and backups in advance. If this is ready before the start, the penetration test is spent on finding real problems rather than waiting for passwords, and your live system gets no surprises.

Below is a table of what to prepare, why and who does it, notes on each item and a checklist you can forward to your team. How to choose a provider is covered in 10 questions to ask a pentest company, and what drives the price in what a pentest includes and what it costs.

In short

• The scope (what exactly is tested) must be on paper: systems, addresses, environments, user roles and what stays out of the test.
• The permission and rules of the work are signed by someone who can decide for the company. No active testing starts without it.
• As of October 2026, AWS, Microsoft Azure and Google Cloud do not require prior approval for an ordinary pentest of your own resources, but each has its own prohibitions. Ordinary hosting has its own rules.
• Before the start, take a fresh backup and make sure it actually restores.
• The report is useful only when every finding has an owner and a deadline. The retest (a second check after fixes) shows what is really closed.

What to prepare: a table for the client

Scope: systems, environments, roles

Start with a list of what you have: domain names, API addresses, server IP addresses, mobile apps, admin panels. Next to each item, write why it matters to the business and what data it holds. Then the provider understands where depth matters and where a lighter check is enough.

Describe user roles separately: customer, manager, administrator, partner. Create at least two test accounts for each role. This lets the tester check the most common web application problem: whether one customer can see another customer's orders or documents.

Name what is out of scope too. A payment provider, a cloud CRM or an email service belong to other companies and cannot be tested without their owner's permission. The NCSC recommends that scoping involves the risk owners, technical staff and a representative of the test team. ^[5]

Written permission and rules of engagement

The permission protects both sides: you from damage, the provider from an accusation of unauthorised access. Rules of engagement (how the testers behave during the test) usually cover:

• which systems may be tested and from which tester IP addresses;
• the dates and hours when active testing is allowed;
• what is forbidden: load attacks, deleting data, emails to real customers;
• whom to call if the site slows down, and how to stop the test;
• what the provider does after finding a critical problem: reports it straight away instead of waiting for the report.

NIST describes the planning and rules of security testing in its testing guide. ^[4] The document is signed by someone who actually has the right to grant access to the company's systems.

Cloud and hosting: do you need to notify anyone

The rules of the large clouds as of October 2026:

• AWS. No prior approval is needed for services on the permitted list. Denial of service attacks (DoS, overloading a service with requests) and several other actions are forbidden. Covert attack simulations and command and control servers (C2) need a separate request at least two weeks in advance. ^[1]
• Microsoft Azure. You do not need to notify Microsoft, but Microsoft's cloud penetration testing rules apply: test only your own resources, no DoS. ^[2]
• Google Cloud. You do not need to notify Google. Tests must affect only your projects and follow the Google Cloud usage rules. ^[3]

Ordinary hosting and VPS providers have their own terms. On shared hosting other customers sit next to you, so only your site is tested. Read the contract or write to support in advance. If the site sits behind a WAF (a filter for web requests) or a CDN, decide whether to allowlist the testers' addresses: otherwise the protection may block the test, and you get a result about the filter rather than the site.

Provider rules change. Before the start, open your provider's current page instead of relying on an article, including this one.

Backups, staging or production

A staging environment (a copy of the system for testing) is safer: more aggressive scenarios can be tried there. But it must resemble production: the same code version and the same access settings. Some problems live only in production, such as server misconfiguration or unnecessary open services. Often staging is tested in depth and the production perimeter is checked carefully during agreed hours.

Before the start, take a fresh backup and try restoring it. A backup that has never been restored is a hope, not a plan. Do not keep real customer personal data on staging: made up records work just as well.

What to tell your team

Management, administrators, support and whoever watches the logs should know about the pentest. Otherwise support gets strange requests from test accounts and an administrator blocks the tester in the middle of the work.

Sometimes a company deliberately does not warn the people who watch security, to see whether they notice the attack. That is fine, but then at least one trusted person knows about the test and can stop an escalation. Do not plan big releases during the test, or tell the provider about them.

How to read the report and what to do with it

A good report has a short summary for management and technical details for the team. How to judge its quality is covered in the article on choosing a provider. When the report arrives:

1. Read the summary and make sure you understand how each critical finding threatens the business.
2. Give every finding an owner and a deadline. Critical issues are closed first.
3. Fix the cause, not one form field: a similar mistake often sits in neighbouring places.
4. If you decide not to fix something, record it as an accepted risk with a signature.

The NCSC reminds clients that risk and fix decisions stay with the client, not with the testers. ^[5]

The retest

The retest checks the same findings after your fixes. Agree before the start whether it is included in the price and when it happens. Ask for written confirmation of which problems are closed and which are not. A retest does not look for new issues: if you have changed the system significantly, you need a new pentest, not a repeat.

Preparation checklist

• The list of systems, addresses and environments is agreed in writing.
• What is out of scope is written down, including third party services.
• At least two test accounts exist for each role.
• The NDA and the permission with rules of engagement are signed.
• Dates, hours and a channel for urgent messages are agreed.
• There is a contact on our side who can stop the test.
• The hosting or cloud rules are checked on the provider's current page.
• We have decided what to do with the WAF and CDN during the test.
• A backup is taken and the restore is tested.
• Support, administrators and monitoring are warned.
• An owner for the report and the fixes is assigned.
• The retest and its timing are written into the contract.

Download the preparation checklist (PDF)PDF · A4

FAQ

How long does preparation take?

If your systems are described and one person grants access, a few working days are usually enough. The longest waits are for the signed permission and the test accounts, so start with those.

Can we test only production, without staging?

Yes, if the rules account for it: more careful checks, agreed hours, a fresh backup and a person on call. Aggressive scenarios are better left for staging.

Should we give pentesters administrator passwords?

It depends on the goal. A test "from the outside" needs no access. A test of access rights needs test accounts with different roles. Never hand over employees' real passwords.

Do we need to notify AWS, Azure or Google Cloud?

As of October 2026, an ordinary pentest of your own resources needs no prior approval, but you must follow each provider's rules. AWS separately requires a request for covert attack simulations. Check your provider's current page before the start.

What if a critical problem is found during the test?

The provider should tell you straight away, without waiting for the report. Agree in advance who receives such a message and who decides whether to fix it immediately or continue the test.

References

1. AWS: Penetration Testing aws.amazon.com
2. Microsoft Cloud Penetration Testing Rules of Engagement microsoft.com
3. Google Cloud Security FAQ support.google.com
4. NIST SP 800-115: Technical Guide to Information Security Testing and Assessment csrc.nist.gov
5. NCSC: Penetration testing ncsc.gov.uk