VAPT & Penetration Testing
How to prepare for a penetration test
A plain checklist for business owners: scope, written permission, test accounts, backups and who to call, so your penetration test runs smoothly.
A penetration test goes best when the business has done a few things before the first request is sent. You need to agree what is being tested, give written permission, name a contact who will answer the phone, and have test accounts ready. None of this needs technical skill. Most of it is decisions only you can make.
This guide is a plain checklist for the founder or IT contact who has just booked a test, or is about to. It also includes an example outline of a permission and scope document, so you know what yours should cover. If you are still choosing between a scan and a test, read about penetration testing first, then come back here.
What a test needs from you
A tester can only work with what you give them. Before the start date, collect five things.
- A list of what to test. Website addresses, app names, API addresses, and the environment (live or staging).
- Written permission from someone who has the authority to give it.
- A contact person who is reachable during the test, plus a backup.
- Test accounts for each user role in your app.
- Documentation you already have, such as an API description or a simple diagram of how the system fits together.
If you cannot answer one of these yet, say so. A tester would rather hear "we do not know who hosts the API" in week one than find out halfway through.
Decide what is in scope and what is not
Scope is the list of systems the tester may touch. Anything not on the list is off limits, even if it looks connected. Write the list as exact addresses, not descriptions. "Our website" is vague. "https://www.example.com (opens in a new tab) and https://app.example.com (opens in a new tab)" is clear.
Think about these questions.
- Live or staging? Testing a staging copy is safer, but only useful if it matches live closely. Testing live finds real problems and carries more risk. Some teams test staging first, then run a shorter check on live.
- Which parts matter most? Login, payment, admin pages and anything that holds customer data usually come first.
- What do you not own? Payment gateways, email services, analytics tools and other third-party services are not yours to test. List them as out of scope. You can test how your app connects to them, not the provider itself.
- What is off limits for business reasons? An old system that is about to be shut down, or a server shared with another company, may need to be excluded.
Do not narrow the scope only to make the report look better. A tester who cannot see the weak system cannot report on it.
Give written permission, including for third-party hosts
Testing without permission may break the law, and your lawyer can tell you how it applies to you. The tester starts only once the owner has agreed in writing. This protects both sides. Your permission should name who is allowed to test, which systems, and between which dates.
Permission has a second layer. If your site runs on a hosting company or cloud platform, the platform has its own rules, and your permission does not override them. Check the official policy of each provider you use.
- AWS. The AWS penetration testing page (opens in a new tab) says testing of the permitted services does not need prior approval. It does say that all testing that includes command and control (C2) requires prior approval, and that testing services not on the approved list means working with AWS Support or your account representative. Denial of service attacks, including simulated ones, and flooding of login or API requests are prohibited. Other simulated events, such as phishing or malware tests, go through AWS's Simulated Events form, so check the page for the notice it currently asks for.
- Microsoft Azure. The Microsoft security testing rules of engagement (opens in a new tab) require that testing stays within your own tenant, or assets you have explicit written consent to test. Denial of service testing and any interaction with data or systems you do not own are prohibited.
- Google Cloud. The Google Cloud FAQ (opens in a new tab) says you do not need to notify Google before testing your own projects. You must follow the Acceptable Use Policy and Terms of Service, and your tests must only affect your own projects.
These policies change, so read the current page on the day you book. Shared hosting, managed WordPress hosting and other small providers often have no public policy. Ask their support team in writing and keep the reply.
Example outline of a permission and scope document
This is an example outline only, to show what such a document usually covers. It is not legal advice and not a finished contract. Have a lawyer review the real one before anyone signs it.
| Heading | What goes under it |
|---|---|
| Parties | Legal name of the business giving permission and of the testing company, with a named signatory for each. |
| Authority | A statement that the signatory has the right to authorise testing of the listed systems. |
| Systems in scope | Exact addresses, app names and environments. |
| Out of scope | Systems and third-party services that must not be touched. |
| Dates and hours | Start and end dates, and the hours testing may run. |
| Allowed methods | The kinds of testing agreed, for example web application testing and API testing. |
| Banned methods | Anything excluded, such as denial of service, phishing of staff or physical entry. |
| Data handling | How findings and any captured data are stored, who can see them, and when they are deleted. |
| Contacts | Names, phone numbers and emails for both sides, plus an emergency contact. |
| Stopping rules | When the tester pauses and calls you, for example on finding customer data or a system going down. |
| Third-party approvals | Which hosting or cloud providers were checked, and what they said. |
| Signatures and date | Signed by both parties. |
Set rules: hours, banned techniques, who to call
Rules of engagement are the practical side of the document above. Agree these before the start.
- Hours. Some businesses prefer testing outside trading hours. Others want it during the day so staff can watch for problems.
- Banned techniques. Denial of service is the common exclusion, because it can take your site down. Phishing staff and testing physical access are separate services and only happen if you ask for them.
- Who to call. Name one person for urgent issues and one backup. Give both a mobile number.
- When to stop. Agree that the tester pauses and phones you if they find something serious, such as exposed customer records, rather than waiting for the final report.
Prepare test accounts and documentation
Most real problems in web apps sit behind a login. Create accounts so the tester does not have to guess.
- One account for every role: ordinary user, staff, admin.
- At least two accounts per role, so the tester can check that user A cannot reach user B's data.
- Fake or sample data only. Do not load real customer records into test accounts.
- Payment testing through your gateway's test mode, never with real cards.
Share the credentials through a password manager or another secure channel, not by plain email. Change or delete the accounts after the test.
Documentation saves time. An API description, a list of user roles and a short note on how login works are enough.
Take backups and warn your team and host
Testing is controlled, but systems can still behave oddly. Take a fresh backup of the database and files before the start date, and confirm that you can restore it. Tell the people who need to know.
- Your team, so nobody treats the test traffic as a real attack.
- Your host or cloud provider, where their policy asks for it.
- Your monitoring or security provider, if you have one, so they do not block the tester or raise a false alarm.
- Developers, so they avoid deploying big changes mid-test. Changes make results harder to trust.
What happens next
After kickoff, the tester works through the agreed scope and keeps in touch through the contact you named. At the end you get a written report. Findings are ranked by risk, each with a clear fix. Once you have fixed the issues, there is a re-test. Before any work starts, you get a plan and a quote.
One-page checklist
- Systems listed by exact address, with out-of-scope items named.
- Written permission signed by someone with authority.
- Hosting and cloud provider policies checked, and replies saved.
- Hours, banned techniques and stopping rules agreed.
- Two contacts named, with mobile numbers.
- Test accounts created for every role, with fake data.
- Documentation shared.
- Backup taken and restore confirmed.
- Team, host and monitoring provider told.
Next step
If you want a test planned around your own systems, penetration testing at Hackers Family starts with written permission and a plan and quote before any work begins.
