Penetration testing methodology
By The PenTest Index · Sources checked October 9, 2026
A penetration testing methodology is the documented way a test is planned, carried out and reported, so others can see what was checked and what was not. Providers usually build their own from public references such as NIST SP 800-115, PTES and the OWASP testing guides. Naming one in a proposal does not show what gets tested on your system.
Below: which reference fits your test, how the phases line up, and seven questions that turn a provider's methodology paragraph into a yes, a no, or a question to send.
On this page
Which penetration testing methodology fits your test?
You usually don't pick one. The provider brings its own, and your job is to check that it fits what you are testing and what your report reader needs. The big exception is where PCI DSS Requirement 11.4 applies: it says the methodology has to be yours.
CREST, an international cyber security membership body, puts it this way in its buyer's guide: "most suppliers have developed their own methodologies," and can show how they line up with the public ones if asked. (CREST, A Guide to Penetration Testing, 2022, read October 9, 2026)
So start from the thing being tested. This table is our reading of what each public reference says it covers. Use it as a starting point for the conversation.
| You are testing | References a provider is likely to name | The question that matters |
|---|---|---|
| A web app | OWASP Web Security Testing Guide for the checks, inside a start-to-finish process such as PTES or NIST SP 800-115 | "Which version, and how will you cover our user roles and the things only our app does?" |
| An API | OWASP API Security Top 10 (2023) as a risk list, plus API checks from the OWASP testing guide | "Is the API tested directly, or only through the app?" |
| A mobile app | OWASP's mobile standard and testing guide (MASVS and MASTG) | "Do you test the app, the API behind it, or both?" |
| A network, inside or outside | NIST SP 800-115, PTES or OSSTMM | "Where do you start from, and how far do you go once you are in?" |
| A cloud setup | The references here were not written for cloud platforms, so providers use their own checklists | "Can we see your cloud checklist, and what does our cloud company allow?" |
| Systems subject to PCI DSS Requirement 11.4 | Your own written methodology under PCI DSS 11.4.1, plus the provider's | See the PCI DSS section |
| A medical device | See our page on testing a medical device | |
| Not sure yet | Start from who asked for the test | Work it out from the request |
Three words get mixed up, so here is how we use them. A penetration test (pentest) is an authorized attempt to break into a system to show what an attacker could reach. A standard or framework is a public document, like the ones in the table. A methodology is how one team actually works, usually built from several of those documents.
Looking for how we research and compare offers on this site? That is our editorial method, a different thing.
What are the main penetration testing standards?
A handful of names come up again and again, and they do different jobs. Two describe a whole test from start to finish. Several say what to check in an app. One measures security more broadly. One is card-industry guidance. And one that often appears in the list is not a methodology at all.
| Reference | Published by | Version we could confirm | What it is | What it does not give you |
|---|---|---|---|---|
| NIST SP 800-115 | US National Institute of Standards and Technology | Final, September 2008 | A government guide to planning and running security tests, with a four-phase penetration test | Anything about technology that came after 2008 |
| PTES (Penetration Testing Execution Standard) | A volunteer group of testers | Calls itself v1.0; main page last edited August 16, 2014 | Seven sections covering a test from the first conversation to the report | Step-by-step technical guidance. PTES says that lives in a separate technical guide |
| OWASP Web Security Testing Guide (WSTG) | OWASP Foundation | v4.2 is the stable release; v5.0 is in development | A catalog of web app checks grouped by topic | Your test's exact scope or priorities. OWASP also says not to treat it as a checklist |
| OWASP ASVS | OWASP Foundation | 5.0.0 | A list of security requirements an app can be checked against | How to run the test |
| OWASP Top 10 and API Security Top 10 | OWASP Foundation | 2025 and 2023 | Short lists of web and API security risks. OWASP calls the Top 10 "a standard awareness document" | A test plan, a scope or a report format |
| OWASP MASVS and MASTG | OWASP Foundation | Current editions on the project site | A security standard and a testing guide for mobile apps | Coverage of the servers and APIs behind the app |
| OSSTMM | ISECOM | Version 3 | A way to test and measure security across people, buildings, wireless, phones and data networks | A hands-on guide to testing apps. OWASP describes it as a supporting reference |
| PCI SSC Penetration Testing Guidance | PCI Security Standards Council | v1.1, September 2017 | Extra guidance for card-data tests | The requirement itself. It says it "does not supersede, replace, or extend PCI DSS requirements" |
| MITRE ATT&CK | MITRE | Updated often | A knowledge base of attacker tactics and techniques. Not a methodology | Scoping, phases or a report format |
All versions and dates were read on each publisher's own page on October 9, 2026.
Three things follow from that table.
Old does not mean wrong. The shape of a test (plan it, look, prove, report) has not changed since 2008. The technology has. If a proposal leans on NIST SP 800-115 or PTES, ask how the provider covers what those documents came before.
Most providers combine them. One reference gives the overall process and another gives the list of checks. Cobalt, for example, publishes its methods by asset type and says its testers "follow specific methodologies for different test and asset types." (Cobalt methodology docs, provider-published, read October 9, 2026) We mention it to show what a published method looks like, not to recommend it.
"OWASP" on its own tells you very little. It could mean the testing guide, the requirements list or a ten-item risk list. Those are three very different promises, so ask which one and which version.
What are the phases of a penetration test?
Every methodology follows the same arc: agree the job, learn the target, find weak points, prove which ones are real, see how far they lead, and write it up. NIST draws that as four phases. PTES draws it as seven sections.
Here they are side by side. The alignment is ours. The phase names are theirs.
| What happens | NIST SP 800-115 | PTES | What you should get |
|---|---|---|---|
| Agree the job | Planning | Pre-engagement Interactions | Written scope, rules, dates, contacts and signed permission |
| Learn the target | Discovery, part one: information gathering and scanning | Intelligence Gathering, Threat Modeling | Questions from the tester, and a request for accounts or documents |
| Find weak points | Discovery, part two: vulnerability analysis | Vulnerability Analysis | A list of suspects. They are not confirmed by exploitation yet |
| Prove what is real | Attack | Exploitation | A fast heads-up on anything urgent |
| See how far it leads | Attack, which can loop back to discovery | Post Exploitation | Evidence of what an attacker could actually reach, inside the agreed limits |
| Write it up | Reporting | Reporting | A report with scope, method, findings and limits |
Two details from NIST are worth knowing. In the planning phase, "No actual testing occurs." And reporting is not only the last step: NIST says it runs alongside the other three, with logs kept during the work. (NIST SP 800-115, section 5.2.1, read October 9, 2026)
Think of a pilot's checklist. It does not fly the plane, and it does not make a bad pilot good. It shows nothing was skipped. The comparison stops there, because a tester has to improvise far more than a pilot does.
Why do some guides show four, five or seven phases?
Because they cut the same work into different slices. Four comes from NIST's penetration testing model. Seven comes from PTES. The five- and six-phase versions you see elsewhere split or merge those steps. NIST also describes a separate three-phase model for security assessments in general (planning, execution, post-execution), and that one sometimes gets quoted as if it were the pentest model.
The number does not matter. What matters is whether the provider can tell you what happens in each step on your system. For the hands-on version, see how to do a penetration test in 8 steps.
How do you check a provider's methodology?
Ask for the provider's own written method and put seven questions to it. If the answer is in writing, you can rely on it. If it is missing or vague, treat it as an open question, not as a no.
| # | Ask | A clear answer looks like | Still open if |
|---|---|---|---|
| 1 | Which references and versions do you use for each part of our scope? | A named reference and version for the app, the API and the network separately | "We follow OWASP and NIST" |
| 2 | Can we read your written method before we sign? | A document or public page describing the steps | "It's proprietary" |
| 3 | Does the method cover every target, user role and key workflow we listed? | Each one named in the written scope | A target is "probably included," or sits in the exclusions |
| 4 | What is done by a person, what by tools, and who reviews the findings? | The human role spelled out for this offer | "Hybrid" or "AI-powered" with no detail |
| 5 | How far will you go once you get in, and what stops the test? | Depth and stop rules written into the rules of engagement | "Our standard approach" |
| 6 | Will the report show which checks ran, which were skipped and which were blocked? | A sample report with a coverage record and a methods section about your test | A findings list and one paragraph of boilerplate |
| 7 | What does the retest cover, when does its window start, and what costs extra? | Count, scope, start of the window, deadline to request, and price | "One retest included" |
A "yes" on one row means that one condition is backed by what the provider wrote. It does not say the provider is good, and it does not promise your auditor or customer will accept the report. They decide that.
Offers led by AI or automation get the same seven questions. The label on the offer does not answer any of them.
Already have a tester you like? Run the check on them too. Confirming the provider you have is a good result.
Worked example: a customer portal and a partner API
Fictional example. The company, the proposal and every line quoted from it are invented to show how the check works. No real provider is described.
Say you run a 30-person software company. You need your customer portal and a separate partner API tested. You want standard users and administrators covered, proof that one customer cannot see another's data, a report that shows what was and was not tested, and a check of your fixes afterward. A proposal arrives. Its methodology section reads: "Our methodology follows PTES and OWASP."
The verdict first: as written, this proposal does not fit, because it leaves out the partner API. The methodology paragraph cannot fix that. Here is the row-by-row reasoning.
| What you need | What the proposal says | Finding | Send this |
|---|---|---|---|
| A documented approach | "PTES and OWASP." No OWASP document named, no version, no link to your features | Unresolved. Names are not a plan | "Which OWASP document and version? How do the checks map to our features and roles?" |
| Portal and partner API both tested | Scope lists the portal. Exclusions list the partner API | Mismatch. A required target is excluded | "Please add the partner API to the written scope and price." |
| Standard-user and admin roles | Asks for test accounts but names no roles | Unresolved. Accounts do not tell you which permissions get tested | "Which roles will you test, and how will the report show it?" |
| One customer cannot reach another's data | An appendix includes two test organizations. Another section limits testing to one | Conflicting. The documents disagree | "Please send one scope that says whether cross-customer access is tested." |
| Coverage and limits in the report | Commits to listing completed, skipped and blocked checks with reasons | Supported, for this one promise | "Please show us the report layout." |
| A check of the fixes | "One retest included." No window, no deadline | Unresolved. You cannot tell if you can use it | "When does the window start, when must we ask, what is rechecked, and what costs extra?" |
What to do with that. A mismatch on something you must have takes the offer off the table until it changes. Open questions and conflicts are not a no; they are emails to send. So the route here is to go back to this provider and ask for a revised scope that includes the API and answers the four questions. If the revision covers everything, carry on with them. If they cannot include the API, compare another offer.
Notice what did not decide it. "PTES and OWASP" was neither the problem nor the answer. The scope was.
The message to send
Copy this, fill in the brackets and send it to every provider you are comparing, so the answers line up.
Before we go further, please send:
- Your written testing method for [web app / API / network], with the references and versions you use for each.
- Confirmation that the scope covers [targets], [user roles] and [key workflows], and a list of anything excluded.
- What is tested by a person and what by tools in this offer, and who reviews the findings.
- How testing depth and stop conditions are set.
- A sample report showing the methods section and how you record checks that were skipped or blocked.
- Your retest terms: what is rechecked, how many times, when the window starts, the deadline to request it, and any extra cost.
This message asks questions. It does not give anyone permission to test. Written authorization has to cover the actual targets and activities.
Questions 3 and 7 only work if your own scope is written down first. A provider cannot tell you whether its method covers your roles and workflows until you have listed them. Our scope checklist walks you through that list. It is free to copy or print, with no email or sign-up, and nothing is sent to providers.
Already holding a quote? Carry the open questions into a Quote Check.
Will the methodology be in the report?
It should be, and it should describe your test, not tests in general. Ask for a report that ties the agreed approach to the work actually done, the findings and the limits.
PTES splits a report into two parts: an executive summary for the people who oversee security, and a technical report with the details. (PTES, Reporting, read October 9, 2026) On top of that, we suggest asking for a coverage record. That is our recommendation, not a rule from any standard. It looks like this:
Fictional illustration of a coverage record.
| Scope item | Status | Where the evidence is | Limit |
|---|---|---|---|
| Portal administrator functions | Completed | Report section named by the tester | Applies to the build and environment tested |
| Partner API | Not tested | Scope exception note | Excluded from the original offer |
| Cross-customer access | Blocked | Access note | A second test organization was not available |
The third row is why this matters. A check that was blocked is not a check that passed. Without a coverage record, both look the same in a report: no finding.
The same goes for the retest. A methodology may describe a follow-up stage, but that tells you nothing about what your quote includes. Get the count, the scope, the window and the price in the offer itself.
For what else a good report holds, see what a penetration testing report should contain.
Does PCI DSS require a penetration testing methodology?
Yes, where PCI DSS Requirement 11.4 applies, and it has to be your organization's own. PCI DSS v4.0.1 Requirement 11.4.1 says "A penetration testing methodology is defined, documented, and implemented by the entity." Hiring a firm that has a methodology does not cover this by itself. PCI DSS's testing procedure checks whether your methodology includes every element in the requirement.
The requirement lists nine things the methodology must include. In plain words:
- Industry-accepted testing approaches.
- The entire cardholder data environment perimeter and its critical systems.
- Testing from both inside and outside the network.
- Testing that any network segmentation used to shrink the scope really works.
- Application-layer testing that looks for, at a minimum, the weaknesses listed in Requirement 6.2.4.
- Network-layer testing of everything that supports network functions, and of operating systems.
- A review of threats and weaknesses seen in the last 12 months.
- A written way to judge and deal with the risk of what the test finds.
- Keeping test results and fix records for at least 12 months.
Three nearby requirements shape the purchase:
- Who can test. Requirements 11.4.2 and 11.4.3 call for internal and external tests at least once every 12 months and after any significant infrastructure or application upgrade or change, done "per the entity's defined methodology" by a qualified internal resource or qualified external third party that is organizationally independent.
- Fixes get rechecked. Requirement 11.4.4 says exploitable vulnerabilities and security weaknesses found during testing are corrected according to your own risk assessment and "Penetration testing is repeated to verify the corrections." So repeated testing is required when those issues are found; do not assume it is included in the quoted test. Price it in.
- What counts as accepted. The guidance beside 11.4.1 gives OSSTMM and OWASP as examples of industry-accepted approaches and points to the PCI SSC's Penetration Testing Guidance, which also lists NIST SP 800-115 and PTES. That guidance is v1.1 from September 2017 and still uses older requirement numbers, so treat it as background.
In practice, write a short methodology document of your own that covers the nine items, and reference your provider's method inside it. Then ask your assessor whether it meets their reading before you book the test.
Source: PCI DSS v4.0.1, June 2024, Requirements 11.4.1 to 11.4.4, printed pages 274 to 278, read October 9, 2026. Get the official copy from the PCI SSC document library. This is general information, not compliance advice.
What if a customer or auditor asks which methodology you follow?
Ask them what they need before you answer, because they decide what they accept. We have not found one methodology that every customer or auditor requires, so a framework name is rarely the whole answer.
Send the person who asked these three questions:
- Which systems must the test cover, and is anything excluded?
- What must the report show about methods and coverage, and by when?
- Does the tester have to be independent of us, or hold particular qualifications?
Their answers become conditions in your scope. If a rule you answer to names penetration testing, read the rule itself: we keep a source-by-source list of which rules ask for a penetration test, and a separate page on SOC 2 penetration testing.
Are black box, gray box and white box methodologies?
No. They describe how much the tester is told and given before starting. Any methodology can be run at any of the three levels.
CREST's guide defines them by the information provided: none for black box, limited information such as login details for gray box, and full information such as network maps and access to developers for white box. Providers stretch these labels in different directions, so agree on the actual accounts, documents and code access instead of relying on the word.
A scan is a different question again. The guidance in PCI DSS v4.0.1 says "Scanning for vulnerabilities alone is not a penetration test." For the full comparison, see penetration testing vs vulnerability scanning.
Does following a methodology mean the test was good?
No. A methodology shows the work was organized and can be explained. It does not show the tester was skilled, or that everything was found.
The standards say so themselves. CREST's guide says "Any methodology should merely be a guideline," and that good testers shape their approach to each situation. OWASP tells readers to avoid treating its testing guide as a checklist. And the guidance in PCI DSS v4.0.1 is blunt about clean results: a test "that found nothing is typically indicative of shortcomings of the penetration tester."
So treat the methodology as the floor. What tells you more is who does the work, the coverage record, and the evidence behind each finding.
A few more questions
What is the best penetration testing methodology?
There isn't a single best one. They do different jobs, and most real tests use two or more. Match the reference to what you are testing, using the first table on this page, and judge the provider's own method with the seven questions.
Is the OWASP Top 10 a penetration testing methodology?
No. OWASP calls it "a standard awareness document": a short list of the most critical web app risks. A proposal that says only "we test the OWASP Top 10" has told you which risks it has in mind, not what it will do.
Is MITRE ATT&CK a penetration testing methodology?
No. MITRE describes it as a knowledge base of attacker tactics and techniques. Testers use it to label what they found in a common language. It has no scoping step, no phases and no report format.
Do we need to write our own methodology?
Only if a rule you answer to says so. PCI DSS Requirement 11.4 does where it applies. Otherwise your provider's written method, checked against your scope, is normally what you work from.
Sources and how we built this page
We read the documents below on October 9, 2026 and built the tables, the phase alignment, the seven questions and the worked example ourselves. The example proposal is fictional. We did not test any system or buy any service, and none of these organizations endorses this site.
The PenTest Index is an independent publication for penetration testing buyers. We do not perform or authorize testing. See how we research and compare offers and how we make money.
- NIST SP 800-115, Technical Guide to Information Security Testing and Assessment (September 2008): publication record; PDF sections 2.1 and 5.2.1 for the phases.
- Penetration Testing Execution Standard: main page for the seven sections and status; Reporting for report structure.
- OWASP Web Security Testing Guide: release status; latest edition foreword and contents; Penetration Testing Methodologies for OWASP's own list.
- OWASP ASVS, OWASP Top 10, OWASP API Security Top 10 and OWASP Mobile Application Security: current versions and each project's own description.
- ISECOM, OSSTMM: description and version.
- MITRE ATT&CK: its own description.
- PCI DSS v4.0.1 (June 2024), Requirements 11.4.1 to 11.4.4, from the PCI SSC document library; and PCI SSC Penetration Testing Guidance v1.1 (September 2017).
- CREST, A Guide to Penetration Testing (2022): supplier methodologies and testing styles.
- Cobalt methodology documentation: provider-published example of a public method.
Spotted an error or a newer version? Send a correction.