OSSTMM vs PTES: which one should you commission?
Commission PTES when the goal is an engagement-focused penetration test or red team test that ends in a findings report, and commission OSSTMM 3 when the goal is repeatable operational security metrics across several channels. PTES is organized into seven main sections, from pre-engagement interactions through intelligence gathering, threat modeling, vulnerability analysis, exploitation, post exploitation and reporting, so a statement of work can name each phase and the deliverable at the end. Its PTES main page says tests range from a routine web application or network test to a full red team engagement, which makes it a common reference when the engagement itself defines the scope. Ask the provider for a sample findings report and for a map of each PTES section to its work plan before you sign.
OSSTMM 3 fits a buyer who wants to compare operational security over time across five channels: Human, Physical, Wireless, Telecommunications and Data Networks. Its rav is a factual attack surface metric, and the Security Test Audit Report (STAR) is meant to be compared with previous tests, so the same channels and metric can be tracked from one cycle to the next. This matters most for a program that must show trend lines to a board or a regulator. The OSSTMM 3 manual is published under Creative Commons Attribution-NonCommercial-NoDerivs 3.0, so have counsel confirm what that license permits when a provider adapts templates or describes its output as an OSSTMM test. Ask for a sample STAR and an explanation of how the rav is calculated for your environment.
PTES and OSSTMM are not mutually exclusive in principle, but this page does not identify a standard combination, so do not write one into a statement of work by default. A workable approach is to name the governing methodology for each part of the engagement. For example, an illustrative contract might require a PTES-structured penetration test of the web and data network scope while asking for STAR reporting only on the channels where the buyer wants comparable metrics. State which reports are contractual deliverables and who owns them. PTES's planned v2.0 would add intensity levels, so confirm whether the provider will work to v1.0 or to a draft, and fix the version in the contract.
How OSSTMM and PTES differ on structure, reporting and license
This table compares OSSTMM 3 and PTES v1.0 on goal, scope, structure, attack surface measurement, reporting, license and planned changes. Where the supplied sources are silent, the cell says what to confirm with the publisher, so read those cells as open questions for your own procurement check.
| Dimension | OSSTMM 3 | PTES v1.0 |
|---|---|---|
| Primary goal | Tests the operational security of physical locations, human interactions and all forms of communications | Standardizes how a penetration test or red team engagement is planned, executed and reported |
| Scope model | Single methodology applied across five channels, moving away from tests that assume specific products such as a firewall | Tests range from a routine web application or network test to a full red team engagement |
| Structure | Five channels: Human, Physical, Wireless, Telecommunications and Data Networks | Seven main sections: pre-engagement interactions, intelligence gathering, threat modeling, vulnerability analysis, exploitation, post exploitation and reporting |
| Attack surface measurement | Introduces the rav, a factual attack surface metric | No equivalent named metric in the supplied sources; confirm with the publisher before assuming one exists |
| Reporting output | Security Test Audit Report (STAR), intended for comparison with previous tests | Reporting is a main section; confirm the expected report format and content on the source page or with the publisher |
| License | Creative Commons Attribution-NonCommercial-NoDerivs 3.0 (2010 edition) | Confirm the license terms on the PTES source page before reuse or adaptation |
| Planned changes | Not stated in the supplied sources | A planned v2.0 would add intensity levels so an organization can state how sophisticated an adversary it expects |
| Best fit for buyers | Teams that want measurable, repeatable metrics across people, premises and communications, and comparison across tests over time | Teams that want a shared process for scoping, running and reporting an engagement with a provider |
How PTES structures an engagement and how OSSTMM structures a test
PTES organizes the work as an engagement, from first client conversation to final report. Its main page describes seven sections: pre-engagement interactions, intelligence gathering, threat modeling, vulnerability analysis, exploitation, post exploitation and reporting. The technical guidance sits in separate documents, so the standard tells you what stages a test should pass through and leaves the detailed how to those companion pages. The same main page says the standard covers everything from a routine web application or network test to a full red team engagement. That range matters for buyers because the pre-engagement section is where scope, rules of engagement and the intensity of the test get agreed. Before you sign, confirm in writing which sections the provider will follow, which technical guide they use for each, and what they will hand over at the reporting stage.
OSSTMM 3 starts from a different question. It describes itself as a methodology for testing the operational security of physical locations, human interactions and all forms of communications, a scope that grew out of physical and people-focused security work rather than web application testing. It applies one methodology across five channels: Human, Physical, Wireless, Telecommunications and Data Networks. It also moves away from solution-based testing, which assumes a specific product such as a firewall is the control under review, and instead asks testers to measure what is actually exposed. Its factual attack surface metric, the rav, and its Security Test Audit Report (STAR) exist so that one test can be compared with the next. If your board wants a repeatable measure across people, premises and networks, ask a provider how they would populate each channel and how the STAR results would be tracked over time.
What each approach finds and misses
PTES and OSSTMM answer different questions, so each leaves different gaps. The cards below set out what each method tends to surface, where its scope can fail you, and what no single test proves on its own.
PTES follows exploitable paths
PTES is built around intelligence gathering, threat modeling, vulnerability analysis, exploitation and post exploitation, so its findings are usually chains of access that lead from an entry point to something valuable. It is strongest when the scope names the assets, accounts and data that matter. Ask the provider to show which attack paths were tested, which were ruled out, and why.
OSSTMM covers five channels
OSSTMM 3 applies one methodology across Human, Physical, Wireless, Telecommunications and Data Networks, so it can surface operational security gaps such as social engineering exposure, unlocked facilities or unmanaged wireless access. Those findings rarely appear in a network-only penetration test. Confirm which channels are in the statement of work before assuming they were tested.
Neither method guarantees full coverage
A clean PTES report or an OSSTMM STAR only describes what the testers were permitted to touch, within the time they had. Neither method proves that an attacker could not reach a given asset. Ask for the scope boundaries, excluded systems and testing window in writing, and treat any unlisted asset as untested.
Unscoped channels in PTES
PTES does not require every channel to be tested, so a PTES engagement scoped to external network and web targets can miss physical access, staff-facing social engineering and wireless exposure entirely. The risk is a report that looks complete while large parts of the attack surface were never in scope. Require a written list of channels and a stated reason for each exclusion.
Breadth without depth in OSSTMM
Because OSSTMM spans many channels with one method, a test can cover each channel shallowly and miss the exploit chain that a focused PTES engagement would find in a single system. Its rav metric shows how much surface was checked, not how deeply each control was tried. Ask for the testing depth per channel and whether any channel received a dedicated tester.
Validate detections after either test
Neither approach shows whether your monitoring would have noticed the techniques the testers used. Run a validation pass after each test that checks which actions raised alerts, which went unseen and which tickets were opened. This connects the findings to your detection coverage, and it applies equally to a PTES engagement and an OSSTMM audit.
What you receive: a STAR or a findings report
OSSTMM 3 asks testers to complete a Security Test Audit Report, or STAR, so that each test can be compared with previous ones. The STAR is organized around the channels and the factual measurements the methodology defines, rather than around a list of product-specific fixes. That structure is what makes it useful over time: a second test can be set against the first using the same measurement logic, so you can see whether the attack surface changed, not only whether a particular finding was closed.
- Channel-level results: Findings and measurements are grouped under Human, Physical, Wireless, Telecommunications and Data Networks, so you can see which channel changed between tests.
- Factual attack surface measurement: The rav metric is presented as a factual attack surface figure, which gives a board a number to track across test cycles instead of a narrative about risk.
- Comparability with prior tests: Because the methodology is designed for repeated testing, the STAR should let you line up this year's results against last year's on the same basis.
- Scope and limitation statements: Ask how the report records what was tested, what was excluded and what could not be measured in the operational environment.
- Evidence of method: Confirm whether the report shows the tests performed per channel and how results were verified.
Confirm with the provider whether their STAR follows the OSSTMM 3 structure in full, how the rav is calculated and presented, and whether they will supply a redacted sample before you commit.
PTES ends with a reporting section, and its deliverable is a findings report that follows the engagement from pre-engagement interactions through exploitation and post exploitation. The report therefore tends to read as a narrative of what was tested, how access was gained, and what the client should fix. Its value is strongest for the remediation team, which needs reproducible steps and clear priorities, and for application or infrastructure owners who must act on individual issues.
- Engagement narrative: The report typically covers the scope agreed in pre-engagement, the intelligence gathered and the path taken through exploitation and post exploitation.
- Finding-level detail: Expect each finding to carry a description, affected assets, reproduction steps and recommended remediation.
- Prioritization: Ask how severity is assigned and whether the provider uses a named scoring system for ranking.
- Executive summary: Confirm whether a summary for leadership is included alongside the technical body.
- Retest approach: Ask whether the findings report defines how fixed issues will be verified in a later test.
The PTES main page describes the standard in terms of its sections, which gives you a checklist for the report's coverage. Request a sample findings report and check it against the reporting section of PTES before you accept the deliverable.
The practical difference is what each report is built to answer. A STAR is designed to answer whether the attack surface moved between tests on a consistent basis. A PTES findings report is designed to answer what was found on this engagement, how it was reached and what to fix first. Many buyers need both answers, and the choice of format determines which question the next test cycle can answer well.
- Trend questions: A STAR supports year-on-year comparison of the same measurements.
- Remediation questions: A findings report supports ticket creation and fix verification.
- Board questions: A STAR's factual metric can anchor a trend chart, while a findings report usually needs a separate summary for leadership.
- Audit questions: Auditors often ask for evidence of scope, method and remediation, so check which format maps to the evidence your assessor expects.
- Mixed needs: Some teams ask for a findings report for remediation and a comparison summary for governance.
Before you sign, ask each provider for a sample of their report, confirm in writing what the deliverable contains, and agree on who owns the report and its data after the engagement ends.
Questions buyers ask before commissioning OSSTMM or PTES work
What drives the cost of an OSSTMM or PTES engagement?
The price follows the written scope, not the methodology name. Buyers pay for tester time across planning, testing and reporting, plus travel, on-site work and any retesting. The method changes the work mix. OSSTMM 3 applies one methodology to five channels (Human, Physical, Wireless, Telecommunications and Data Networks), so a multi-channel scope adds test areas, approvals and specialist effort. PTES work is organized around its seven sections, and its threat modeling and exploitation effort grows with the adversary profile you choose. Both are one-time costs per test, but recurring annual or quarterly tests add up. DeployOpen does not publish a price list. Request a quote that lists channels or phases, asset counts, testing windows and retesting.
How long does an OSSTMM or PTES test take?
Neither method sets a fixed duration, so the length comes from the scope in the signed statement of work. The main drivers are the number of channels or applications, the depth of intelligence gathering, whether testing is authenticated, whether exploitation is allowed in production and how many retest rounds are planned. The PTES main page describes its scope as running from a routine web application or network test to a full red team engagement, so the same method name can cover very different amounts of work. Ask the provider for a phase-by-phase schedule, the agreed testing window and the date by which the report will be delivered. Confirm these dates in writing before work starts.
What does my team need to provide for an engagement?
Both methods rely on the same inputs: a signed scope, rules of engagement, named technical and escalation contacts, asset lists and test accounts. NIST SP 800-115 includes a rules of engagement template in Appendix B that you can adapt. OSSTMM engagements that cover the Human or Physical channels usually need approvals from HR, facilities and legal before testing begins. PTES pre-engagement interactions are where scope, threat assumptions and reporting expectations get agreed, so involve the system owners early. Your team should also plan time to review findings, validate fixes and decide which items the security monitoring team should watch for. Confirm monitoring notices and emergency stop procedures before any active testing.
Can an internal team run an OSSTMM or PTES test?
An internal team can run either method if it has trained testers, a documented methodology, evidence handling and enough time away from operations. The harder question is independence, because internal testers may be too close to the systems they assess. NIST SP 800-115 does not endorse one methodology over another and notes that organizations often combine techniques. PCI SSC's penetration testing guidance says a penetration test is essentially a manual process and that running an automated tool alone does not satisfy the requirement. Before you decide, ask your assessor whether independence is required and whether the method and report format are acceptable. Some teams keep routine scanning in-house and buy periodic external tests for independence.
Are OSSTMM's metrics worth the effort for my organization?
They are worth the effort when you need repeatable comparisons over time or across channels. OSSTMM 3 introduced the rav, a factual attack surface metric, and asks testers to complete a Security Test Audit Report (STAR) so that later tests can be compared with earlier ones. This helps when a board or regulator asks whether exposure changed. If your main need is a prioritized list of exploitable findings to fix, a PTES findings report may meet that need with less overhead. The metric only has value when scope stays consistent between tests, because changing channels breaks comparison. Read the OSSTMM 3 manual and ask the provider how the rav is calculated and whether they deliver a STAR.
Which methodology will a compliance assessor accept?
No supplied source says that every assessor accepts either method, so confirm this with your assessor before you buy. NIST SP 800-115 does not endorse one methodology over another. PCI SSC's penetration testing guidance sets expectations for manual testing and scope, and DORA Article 25(1) lists penetration testing among the tests a financial entity should run, with threat-led testing required under Article 26 for entities identified by their competent authority. CIS Safeguard 18.4 asks that security measures be validated after each test so detections cover the techniques testers used. Get the assessor's written view on the methodology, the report format and the scope. DeployOpen prepares evidence for assessments but does not issue audit reports or certifications.
How do I compare OSSTMM and PTES quotes side by side?
Compare the written scopes rather than the headline totals. Each quote should state the methodology and version, the channels or phases included, asset counts, testing windows, retesting, the report format and whether a STAR or findings report is delivered. Ask whether production exploitation is included, who holds test accounts, how scope changes are priced and which costs recur. Ask each provider for a sample report in the format you will receive. Because the OSSTMM 3 manual is published under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 license, confirm with your counsel how that license affects the wording and reuse of any report that cites the methodology. DeployOpen's quotes follow from written scope, and deliverables are agreed before work starts.
What drives the cost of each approach
OSSTMM and PTES price differently because they scope work differently. The drivers below decide how many hours, people and report cycles a test needs, and which costs repeat when you test again for trend comparison.
Scope breadth across channels
OSSTMM 3 applies one methodology to five channels: Human, Physical, Wireless, Telecommunications and Data Networks. Each channel added to scope adds test time, specialist skills and rules of engagement to agree. A PTES engagement is usually scoped around a target application or network, so breadth is set by the statement of work rather than by the channel model. Ask the provider which channels are priced, which are optional, and how a channel you add later is quoted.
Number of in-scope targets
Cost rises with the count of hosts, applications, sites or staff in scope, and with how many distinct test cases each target needs. Ask whether the quote is per target, per day or fixed for a defined boundary, and what happens when the target list grows mid-engagement. Recurring tests often shrink or grow the list, which changes the baseline you compare against.
Depth of exploitation and post-exploitation
Validating a finding with a working exploit, then pivoting, escalating privileges or moving laterally, takes more time than identifying the weakness alone. PTES treats exploitation and post-exploitation as separate phases, so buyers can pay for them explicitly. Confirm in writing whether post-exploitation is included, what limits apply to data access, and how a stop condition is handled if the tester reaches a critical system.
Time to produce the report
An OSSTMM STAR and a PTES findings report both require analysis and writing after testing ends. A STAR is built to compare results across tests, so its metrics and raw test data take time to organize consistently. Ask for a sample of each deliverable before signing, and confirm how many review rounds and remediation walk-throughs the quote includes.
Buyer pre-engagement effort
Much of the cost sits on your side: defining rules of engagement, approving contacts, arranging test accounts, and agreeing on which channels and times are allowed. PTES places pre-engagement interactions first for this reason. Budget internal staff time for these steps, and ask the provider which of them they will draft and which you must supply.
One-time setup and recurring retests
The first test carries setup costs: scoping, baseline capture and agreeing metrics. Later tests reuse that baseline, so they are cheaper only if scope and method stay the same. Retests to confirm fixes are a separate line item that recurs. Ask how a repeat test is quoted, whether metrics stay comparable across years, and what a retest of a single finding costs compared with a full cycle.
How to combine OSSTMM and PTES in one program
This sequence turns OSSTMM's channel-based scope and factual metrics and PTES's engagement structure into one program, so each test is comparable to the last and its findings can be checked against the detections your team actually has.
Define goals and channels in scope
Start with a written statement of what the program must answer, such as whether physical access, staff behavior, wireless exposure or data networks carry the risk you care about. Map each concern to one or more OSSTMM channels (Human, Physical, Wireless, Telecommunications and Data Networks) and record which channels are out of scope and why. Done means the security lead and the system owners have signed a one-page scope that names every channel and the business reason for including it.
Write the rules of engagement
Draft the rules of engagement before any testing begins, covering permitted techniques, testing windows, named contacts, escalation paths, data handling and stop conditions. NIST SP 800-115 provides a rules of engagement template in its Appendix B that you can adapt, and PTES's pre-engagement section covers the same ground in more depth. Done means the rules are approved by legal, the asset owners and the testing provider, and each channel in scope has its own permitted activities listed.
Run the chosen method per channel
Assign each in-scope channel to a PTES-structured engagement, using pre-engagement, intelligence gathering, threat modeling, vulnerability analysis, exploitation and post exploitation in turn, and apply OSSTMM's operational checks where a channel calls for them. Testers record what they tried, what they reached and what they could not test. Done means every in-scope channel has a completed test log that a reviewer can follow without asking the tester.
Produce the report and the STAR
Write the PTES reporting section as the findings report for remediation, and complete OSSTMM's Security Test Audit Report (STAR) as the comparison record. Keep the two documents linked by the same test identifiers so an engineer can trace each finding to the channel and the measured attack surface. Done means the STAR records the scope, the channels tested, and the factual results, and the findings report contains prioritized, reproducible issues with owners assigned.
Validate detections for techniques used
Compare the techniques the testers used against what your monitoring and response teams saw during the exercise. CIS Safeguard 18.4 asks for security measures to be validated after each test so that detections cover the techniques the testers used, and this step is where that check happens. Done means every technique used has a recorded result, either detected, partially detected or missed, and each gap has a tracked remediation item or a documented acceptance.
Repeat the cycle for trend comparison
Run the same channels and the same STAR structure again on a defined schedule so results can be compared across cycles. NIST SP 800-115 suggests scheduled scanning interspersed with periodic penetration testing, and the CIS annual test expectation in Safeguards 18.2 and 18.5 can anchor the cadence your organization chooses. Done means the second STAR shows which factual metrics changed, which findings closed, and which channels need a different scope in the next cycle. Ask your provider to confirm how the STAR and findings report will be retained for comparison.
What the license and compliance context mean for your choice
Start with the license, because it decides what you can do with the manual itself. OSSTMM 3 is published under Creative Commons Attribution-NonCommercial-NoDerivs 3.0. In plain terms, you may copy and share the manual and cite it, with attribution to ISECOM. NonCommercial means the text cannot be used in a way aimed at commercial advantage or monetary compensation, so a paid service sold on the strength of the manual needs legal review before it goes into a statement of work. NoDerivs means you may not publish a modified version of the manual. A bank that wants an internal playbook with its own control mappings, severity wording and reporting templates is adapting the work, so the safe path is to cite OSSTMM 3 and write your own procedures alongside it, then have counsel confirm the boundary. Check the license terms on the ISECOM site directly, since the supplied facts do not cover how those terms apply to your use.
The PTES license is a separate question that the supplied facts do not answer. Before you adopt its wording in a contract or internal standard, confirm its current license on the PTES main page and any technical guidance you plan to reuse, and record the answer in your procurement file. On the compliance side, NIST SP 800-115 states that NIST does not endorse one methodology over another, so neither document is mandated by NIST. The supplied facts also do not show PCI SSC or DORA naming OSSTMM or PTES. Ask your QSA or the assessor who will review your testing evidence whether they accept a methodology built on OSSTMM's channels and metrics, or one built on PTES phases, and get the answer in writing. For DORA, ask your competent authority how it expects a threat-led or penetration test to be documented before you pick a method.
Set the decision up as a short written check: confirm license terms for each method with counsel, confirm acceptance with each assessor and regulator, then choose. If a method is not accepted for your audit, the cost of rework lands on the engagement, so the check should come before the scope is written. Ask your testing provider to state in the proposal which methodology will structure the work and how the output maps to the evidence your assessor requests.
What to put in the statement of work
This sequence turns a choice between OSSTMM and PTES into a written scope that a tester can price, run and be held to. Each step produces an artifact the buyer can check before testing starts or before the report is accepted.
Name the methodology and its version
Start by stating in the statement of work which methodology governs the test: OSSTMM 3 or PTES, and for PTES the version it cites (the main page describes v1.0, and a v2.0 is only planned, so confirm the version you are buying against). Ask the vendor to state how the methodology's phases map to the engagement, including where PTES's pre-engagement, threat modeling and reporting sections, or OSSTMM's channel-by-channel process, will appear in the deliverables. The output is a single methodology clause that both parties can quote back. Confirm with the provider that the named version is the one their testers were trained on.
List the channels or layers in scope
Name every channel or layer the test covers. For OSSTMM 3 this means the five channels (Human, Physical, Wireless, Telecommunications and Data Networks), with each one marked in scope or out of scope. For a PTES-style engagement, list the network, web, and other layers and the internal or external vantage points. Illustrative example: a bank might scope Data Networks and Human interactions but exclude Physical access to a data center. The check that closes this step is a scope table that a reader can use to tell whether a finding falls inside the agreement.
Set rules of engagement for windows and exclusions
Write rules of engagement covering testing windows, out-of-scope systems and third-party assets, emergency contacts, and what the tester must do if a live system degrades. NIST SP 800-115 provides a rules of engagement template in its Appendix B that buyers can adapt. Name any system that hosts data or services owned by a third party and confirm that the owner has authorized testing. Agree how social engineering and physical actions are approved, since OSSTMM's human and physical channels depend on it. The output is signed rules of engagement with a named escalation contact on both sides.
Define the deliverable as STAR or a findings report
Decide which deliverable you need. OSSTMM asks testers to complete a Security Test Audit Report (STAR) that can be compared with previous tests, and it reports the rav attack surface metric. PTES's reporting section typically produces a findings report with prioritized issues and remediation guidance. Specify the format, the contents, the metric definitions, and who receives the document. Ask the provider to show a sample redacted report from their own practice, and confirm whether the STAR's metrics will be reproducible across tests. The closing check is an agreed report outline attached to the statement of work.
Agree the handling of sensitive findings
Specify how critical findings are reported during the engagement rather than at the end, who may receive raw evidence, how credentials and personal data captured during testing are stored and destroyed, and the retention period for working files. Confirm the classification of the report itself, since a STAR or findings report often describes exploitable paths. The output is a data-handling clause and a notification procedure that the buyer's security team has reviewed.
Agree the retest approach
Define whether and how fixes will be verified. State which findings require retesting, whether retesting uses the same methodology and channels, and whether the STAR baseline will be updated after remediation. CIS Controls v8.1 Safeguard 18.4 asks organizations to validate that their security measures cover the techniques the testers used, so a retest clause should confirm that detection coverage is checked against the findings. Record the retest scope, the acceptance criteria for closed findings, and who signs off. The closing check is a retest clause that names the findings it covers.
Confirm the quote matches the written scope
Before signing, compare the price against the written scope. Ask for a quote that itemizes the channels or layers, the testing windows, the report format, the retest, and any support after delivery. Ask which items are one-time and which recur, such as repeat tests or retainers. Costs rise with the number of channels, the number of testing windows, and the amount of physical or social engineering work, so ask the provider to show how each one moves the quote. DeployOpen issues quotes from written scope and does not publish a price list. The output is a signed statement of work that matches the agreed scope.
How DeployOpen scopes, delivers and supports security testing
DeployOpen plans, runs and documents security testing inside your own infrastructure, and it can help you choose which methodology fits your engagement. Whether the written scope follows OSSTMM channels, PTES sections or a combination, the deliverables are agreed before testing starts.
How we scope
- We confirm in writing which targets, channels or phases the engagement covers before any testing begins.
- We state which methodology sets the test structure, so OSSTMM channel coverage or PTES phases are not assumed.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
How we build
- We run the agreed test phases against the systems named in scope, with rules of engagement set out first.
- We map each finding to the methodology sections or channels it came from, so results stay traceable.
- Where OSSTMM metrics are requested, we confirm how the attack surface data will be collected and recorded.
How we hand over
- You receive documented findings and the report format agreed in scope, whether a PTES-style findings report or a STAR.
- We document the test method, limits and evidence so your team and auditors can review what was done.
- We walk your team through results and agree remediation priorities for the next test cycle.
How we support
- Ongoing support, retesting and repeat assessments are available as a retainer alongside the original engagement.
- Retainers can cover scheduled retests so later results stay comparable to the baseline you chose.
- Ask us to confirm the support terms, scope changes and retest process in your written agreement before signing.
