How to do a penetration test

By The PenTest Index · Sources checked October 9, 2026

How to do a penetration test: get written permission from whoever owns the systems, agree the scope and rules, then have a qualified tester look for weaknesses, prove which ones are real, report them, and retest after the fixes. Who does the testing, your own team or a hired tester, depends on who has to trust the report.

The table below sorts that out first. The eight steps and the test plan you can copy work either way.

Who should do the test: your team, a hired tester, or neither?

If someone outside your company will rely on the report, plan on an independent tester and ask that person what they need before you spend anything. If the test is only for you, a skilled person who does not run the system can do it. Find your row. The order reflects how often we judge each situation comes up.

Two terms, so we mean the same thing. A penetration test (pentest) is an authorized attempt to break into a system to show what an attacker could reach. A vulnerability scan uses software to look for and report possible weaknesses.

On the card data row: the PCI Security Standards Council's penetration testing guidance says "qualified internal resources or a qualified third party" may do the test "as long as they are organizationally independent," meaning separate from whoever manages the systems being tested. That document is supplemental guidance dated September 2017, and it says it does not replace the PCI DSS requirements. So treat it as a pointer, and let the current standard and your assessor decide. (PCI SSC Penetration Testing Guidance v1.1, read October 9, 2026)

Not sure who asked for what? Start from the request.

How to do a penetration test in 8 steps

A penetration test runs in eight steps: set the purpose, decide who tests, write the scope, get written permission, map and test, prove and report, clean up and fix, then retest. Keep the item in the third column at each step. If the fourth column describes you, that step is not finished.

This is our own way of ordering the work. NIST's testing guide draws it as four phases and says that in the planning phase "rules are identified, management approval is finalized and documented, and testing goals are set." You will also see five, six and seven phase versions. They describe the same job cut into different slices. (NIST SP 800-115, section 5.2, read October 9, 2026)

1. Set the purpose and find out who reads the report

Write down the one question the test has to answer. "Can one customer see another customer's invoices?" is a purpose. "Check our security" is not one yet.

Then find out who will read the result, because that person sets the bar. If a customer, auditor or insurer asked for the test, send them these three questions before you do anything else:

1. Which systems must the test cover, and is anything excluded?
2. What must the report show, and by when?
3. Does the tester have to be independent of our company or hold particular qualifications?

Their answers decide step 2. Whether a rule requires a penetration test at all differs from one framework to the next, so we keep a source-by-source list of which rules ask for one. The person relying on your report decides whether to accept it. We can't, and neither can a tester.

2. Decide who does the testing

Pick the route from the first table, then check that the person can actually do the work.

This is skilled work with real risk. NIST says penetration testing "is labor-intensive and requires great expertise to minimize the risk to targeted systems," and warns that systems "may be damaged or otherwise rendered inoperable" during a test. It also notes that bringing in a third party "offers an independent view and approach that internal assessors may not be able to provide." (NIST SP 800-115, sections 5.2 and 6.4)

So ask two things about any tester, in-house or hired. Have they tested this kind of system before? And are they separate from the people who built or run it? Someone checking their own work tends to skip the parts they already believe are fine. That is our judgment, and it is the same reason writers do not proofread their own books.

Already have a tester on contract, or a test bundled with a compliance tool? Read what it actually covers and compare it with the answers from step 1 before you buy anything new. You may already be covered.

One more thing. Offers led by AI or automation are their own kind of offer. Judge them by what they cover and whether your report reader accepts them, not by the label.

3. Write down the scope

The scope is the list of exactly what will be tested. Write it before any testing and before you ask anyone for a price.

Include:

• The systems: app names, web addresses, API versions, network ranges.
• The environment: live production, a staging copy, or both.
• The user roles to test, and whether test accounts will be provided.
• The actions that matter most, like payments, data exports or admin changes.
• What is off limits: systems, techniques, and outside services you use but do not own.
• The deadline for the report.

A scope does for testers what a parts list does for builders. Give every tester the same one and their answers and prices line up. Give each a different story and you can't compare them.

If you are testing a web app or API, our scope questions cover what to settle for each.

4. Get written permission and agree the rules

Nothing touches a system until the person with authority over it has signed off in writing. That includes your own company's systems. Testing a system without the owner's permission can be a crime, and the laws differ by country.

The rules of engagement are the agreed do's and don'ts for the test. Put these in them:

• Who approved the test, and for exactly which targets.
• When testing may happen, and when it may not.
• How far the tester may go once they find a way in.
• What stops the test, who to call, and who can say "carry on."
• What happens if the tester reaches real customer data.
• How evidence is stored, who sees it, and when it is deleted.

Then check three other sets of permission:

• Your cloud or hosting provider. Each has its own policy. Amazon Web Services, for one, says customers may test their own AWS setup "without prior approval" for a published list of services, subject to its policy; testing that includes command and control requires prior approval. Denial-of-service attacks are prohibited under that policy, while DDoS simulations are permitted under separate conditions. Read your provider's current page, because these lists change. (AWS penetration testing policy, read October 9, 2026)
• Outside services you use but do not own, like a payment processor. These are normally out of scope unless that company agrees.
• Your legal contact. NIST recommends that legal advisors "always be involved for intrusive tests such as penetration testing." (NIST SP 800-115, section 6.6)

A scope list or a test plan, including the one on this page, does not by itself grant permission. Get signed authorization that covers the actual targets and activities.

5. Map the target and run the checks

First chart what is exposed. Then test what you planned, and write down every check as you go.

Mapping means listing the pages, API calls, login paths, user roles and servers that are in scope. If you find a server that is not on the list, stop. It is a scope question for the owner, not a new target.

Testing mixes tools and hands-on work. A tool can list a thousand possible issues in an hour. A person then works out which ones are real and what they add up to. For every check, record the target, the version, the account used, the time and what happened. Also record the checks you could not run. A blocked check is not a passed check.

6. Prove the findings and write the report

A weakness counts as a finding once someone has shown it is real. NIST puts the difference this way: scanners "check only for the possible existence of a vulnerability," while the attack phase "exploits the vulnerability to confirm its existence."

Prove it gently. Use made-up test records where you can. You do not need to pull real customer data to show a door is open. If the rules stop you from confirming something, say so in the report.

A useful report has:

• The scope, the dates and what was left out.
• The methods and the level of access the tester had.
• Each finding with evidence someone else could follow.
• A severity rating with the reasoning behind it.
• A suggested fix for each finding.
• What was not tested, and why.

OWASP's testing guide has a free report outline you can follow. It calls the outline "suggestions about one possible approach," not strict rules. (OWASP WSTG v4.2, Reporting, read October 9, 2026)

If the tester finds something urgent, they should tell you right away through the contact in the rules. Don't wait for the final report.

7. Clean up and fix

The tester removes what they added. The system owner fixes what was found. Those are two different jobs done by two different people.

Cleanup covers test accounts, uploaded files and any settings changed during testing. Keep the evidence you agreed to keep.

For fixes, give each finding an owner and a decision: fix it, reduce the risk another way, or accept it and record why. The UK's National Cyber Security Centre is plain about whose call that is: "risk assessment and decisions on the application of fixes are your responsibility." The tester's suggested fix is also not the only option. (NCSC penetration testing guidance, read October 9, 2026)

Until someone has checked a fix, its status is "awaiting retest," not "fixed."

8. Retest and update the record

Run the same check again on the fixed system and write down the result next to the original finding.

A retest means someone repeats the check that found the problem. Some providers call it a rescan. If you are paying for it, ask what is rechecked and who does it. Each finding ends up in one of four states: reported as fixed, verified fixed, still open, or not retested.

A retest covers only what was retested. It does not finish checks that were blocked the first time, and it is not a new test of the whole scope.

What does a finished test record look like?

Here is one finding followed from plan to verified fix, with one check that never ran. The lesson is in the third row of the test log.

Fictional example. The company, systems, accounts, finding and results below are invented to show how the record works. We did not test this application.

Say a small software company wants to check its invoice app before a release. The test is for the company's own product owner. No customer or auditor is involved, so a skilled in-house tester who does not work on the app runs it.

The plan, in short

Four accounts fit this example. Your app may need more.

The test log

Finding F-01: one customer can read another customer's invoice

• Where: staging API version 1, build EXAMPLE-1, the invoice read call.
• Needs: any valid member login in a different customer account.
• Evidence: the logged request and the returned test invoice, with the time and account used.
• Impact: the wall between customers failed on this one path. Other paths were not checked.
• Suggested fix: check the customer account on the server for every invoice request, and review similar calls for the same gap.
• Owner's update, day 4: fix deployed in build EXAMPLE-2. Status: awaiting retest.
• Retest, day 5: the same request on EXAMPLE-2 is refused, and a member of A can still open A's invoices. Status: verified fixed for this path on EXAMPLE-2.

Now look at the third row of the log again. The admin check is still blocked. One verified fix does not turn a blocked check into a completed one, and an honest report says so.

Copy this penetration test plan

Paste this into your own document and fill it in before any testing starts. It records your decisions. It does not authorize testing.

1. Purpose of the test, and the decision it supports:
2. Who will read the report, and the conditions they stated (with where each one is written):
3. System owner, approver, tester, and the reference for the signed authorization and rules:
4. In scope: systems, addresses, environment, build and API version:
5. Out of scope: systems, outside services and activities:
6. User roles, customer account boundaries, test accounts and access provided:
7. The actions and workflows that matter most, and the checks planned for each:
8. Testing dates, report date and retest date:
9. Allowed methods, limits, stop conditions, contact person and who can restart the test:
10. Evidence: where it is stored, who may see it, when it is deleted, and cleanup steps:
11. Test log, one line per check: account used, expected result, actual result, evidence reference, and status (tested, blocked, not tested or out of scope):
12. Findings, one entry each: impact, severity and reasoning, owner, fix status, retest result and what remains open:

Copy test planPrint test plan

Penetration test plan

1. 1. Purpose of the test, and the decision it supports:
2. 2. Who will read the report, and the conditions they stated (with where each one is written):
3. 3. System owner, approver, tester, and the reference for the signed authorization and rules:
4. 4. In scope: systems, addresses, environment, build and API version:
5. 5. Out of scope: systems, outside services and activities:
6. 6. User roles, customer account boundaries, test accounts and access provided:
7. 7. The actions and workflows that matter most, and the checks planned for each:
8. 8. Testing dates, report date and retest date:
9. 9. Allowed methods, limits, stop conditions, contact person and who can restart the test:
10. 10. Evidence: where it is stored, who may see it, when it is deleted, and cleanup steps:
11. 11. Test log, one line per check: account used, expected result, actual result, evidence reference, and status (tested, blocked, not tested or out of scope):
12. 12. Findings, one entry each: impact, severity and reasoning, owner, fix status, retest result and what remains open:

If you do not know an answer yet, write "Unknown, confirm before testing."

This plan records decisions. It does not authorize testing.

From The PenTest Index: https://thepentestindex.com/how-to-do-a-penetration-test/

If you do not know an answer yet, write "Unknown, confirm before testing." Don't leave it blank and don't guess. Keep passwords, keys and details of real weaknesses out of any copy you share.

Can you do a penetration test yourself?

Yes, when the test is for your own use and the person testing has the skill, the time, and distance from the system. If someone else will rely on the report, ask them first, because they may want an independent tester.

Doing it yourself does not shrink the job. You still need the written scope, the signed permission, the log, the report and the retest. What you save is the fee. What you take on is the risk of missing things, and the risk of breaking something with no outside firm sharing the blame.

"Internal" confuses people here. An internal test means testing from inside your network. An in-house test means your own staff do the testing. A hired firm can run an internal test, and your own staff can test from outside.

Here is a quick way to check yourself. If you can't name who will run the checks, who signed the permission and who reads the report, you are not ready to test in-house yet. Fill in fields 1 to 3 of the plan above first.

If you hire a tester: what will it cost and how long will it take?

It depends on your scope, so here are two published offers worked through as examples. They are here because these companies publish their terms, not because we recommend them over others. Nobody quoted us for this example.

Say you have one web app, the API behind it and two user roles.

Price from a published formula. Pentest-Tools.com lists a manual web app test that includes logged-in users at "$3400+ $900/user role." Two roles makes $3,400 + (2 × $900) = $5,200 as a starting amount. That figure does not price extra complexity, and we did not find a retest term on the page. (Pentest-Tools.com web app testing, provider-published, read October 9, 2026)

Time, counted backward from your deadline. Astra lists its Pentest Expert plan at $5,999 per year, counts one web or SaaS app with the APIs it uses as one target, and says the manual test takes "10-15 working days." Its help page sets the manual rescan request window at "30 days from the date the vulnerabilities were reported," with extensions "on a case-by-case basis." (Astra pricing and Astra rescan rules, provider-published, read October 9, 2026)

The trap is the middle of that table. If your fixes take six weeks and the window is 30 days, you will miss the request deadline unless Astra extends it.

Send any tester this question: "For this app, its API and two roles, what is the full price including a retest, and what is the report date in writing?"

Hiring for a web app or an API? Our scope checklist gives you the questions to settle for each, free to copy or print, with no contact details asked. It helps you prepare. It does not pick a provider for you.

Build your scope checklist

When your scope is written, compare published prices, who tests and retest terms.

How long does a penetration test take?

Published testing times for a single web app run from a few working days to 20 working days, and that is the testing alone. On the pages we read on October 9, 2026, Pentest-Tools.com lists 3 working days for a test with no login and 4 or more with logged-in roles, both as best-effort estimates. Astra lists 10 to 15 working days for its manual test on its pricing page, while its duration guide says 10 to 20, depending on scope and pentest volumes.

Add scoping, access setup, the report, your fixes and the retest on top. When a tester gives you a number, ask which of those it covers. A "five-day test" can still mean a report a month from now.

What tools do you need?

Fewer than you would think, because the tools matter less than the person using them. A hired tester brings their own. If you are testing in-house, match the tool to the job:

A tool run is not a penetration test. It can support steps 5 and 6, but it does not complete the whole process.

Where can you practice legally?

In a lab built for it, never on a real business. PortSwigger's Web Security Academy describes itself as "a free online training center for web application security" with interactive labs. Your own test machines at home also work. (Read October 9, 2026)

Practice builds skill. It does not make you the right person to test your employer's live systems next week. And OWASP's free Web Security Testing Guide is the reference many testers work from once they are ready.

A few more questions

Is a vulnerability scan the same as a penetration test?

No. A scan lists possible weaknesses. A penetration test has a person try to use them and show what they lead to. The PCI Security Standards Council's guidance draws the same line: a scan aims to "identify, rank, and report vulnerabilities," and a penetration test aims to "identify ways to exploit vulnerabilities." If someone asked you for a penetration test, a scan report alone is unlikely to satisfy them, so check with them.

Should you test the live system or a staging copy?

Test the one that answers your question. A staging copy is safer and works well for checking how the app behaves. But it only tells you about the live system if the two are set up the same way. If the purpose is "what can an attacker reach right now," that points at the live system, with tighter rules and the owner's sign-off on the risk.

If the test finds nothing, is the system secure?

No. The result covers only the checks that ran, on that version, on those dates. OWASP's report outline says the same: a test is a "point in time" assessment with "no guarantee that all possible security issues have been identified." Blocked and out-of-scope checks stay in the report even when everything else comes back clean.

Is it legal to test your own company's systems?

Get written authorization from someone who has authority over those systems, and stay within your hosting provider's policy. Being an employee is not permission. For anything intrusive, bring in your legal contact before you start. This is general information, not legal advice.

Sources and how we built this page

We read the guidance below and built the route table, the eight-step table, the test plan and the fictional example ourselves. The provider figures are what those companies publish on their own pages. We have not bought their services or tested any system. None of these sources endorses this site, and none of them authorizes your test.

The PenTest Index is an independent publication for penetration testing buyers. We do not perform or authorize testing. How we check offers.

Read October 9, 2026:

• NIST SP 800-115, Technical Guide to Information Security Testing and Assessment (September 2008): phases, risk, tester skills, third-party independence, legal review.
• PCI Security Standards Council, Penetration Testing Guidance v1.1 (September 2017): who may test, scan versus penetration test. Supplemental guidance, not the PCI DSS requirement text.
• NCSC, Penetration testing (published August 8, 2017; reviewed January 10, 2022): scoping, report contents, who decides on fixes.
• OWASP Web Security Testing Guide v4.2, Reporting: suggested report outline and stated limits.
• AWS penetration testing policy: permitted services and prohibited activities.
• PortSwigger Web Security Academy: free training and labs.
• Pentest-Tools.com, web app penetration testing: published prices and timeframes.
• Astra, plans and pricing, duration guide and rescan rules: published price, target definition, testing time and rescan request window.

Further reading from the tool makers: Burp Suite testing workflow, ZAP active scan, Nmap reference guide.