It arrives in one of three ways. A cell in a security questionnaire asks for your most recent penetration test. A security addendum commits you to annual testing by an independent third party. Or a reviewer mentions it on a call, in passing, as though everyone already knew.
Then you start collecting quotes, and they range from a few hundred dollars to more than a month of your engineering budget — for what sounds, from the outside, like the same service.
Two questions are worth answering before you spend anything: does something here actually require a penetration test, and is the thing you are being quoted for a penetration test at all?
What actually requires one
"Required" gets used loosely in these conversations, and most of what is written on this subject is published by firms that sell penetration tests. Here is where the requirement is real, where it is conditional, and where it is habit.
PCI DSS — yes, depending on how you validate. Requirement 11.4 calls for internal penetration testing (11.4.2) and external penetration testing (11.4.3) at least once every 12 months and after any significant infrastructure or application upgrade or change, following your own documented methodology. Two details get missed. The tester does not have to be a QSA or an outside firm at all — a qualified internal resource is acceptable, provided organizational independence from what is being tested exists. And exploitable findings must be corrected and the test repeated to verify the correction, so the budget is the test plus the retest. Not every validation path includes it, either: the simplest self-assessment questionnaires contain no penetration testing requirement at all. Confirm which validation method your acquirer requires before you buy anything.
FedRAMP — yes, and this is the area changing fastest. FedRAMP has historically been the most prescriptive framework on this subject. Its 2022 penetration test guidance requires the test to be performed by a 3PAO, completed no more than six months before the security assessment report is submitted, repeated at least every 12 months, and covering six defined attack vectors — including tenant-to-tenant attacks and a phishing campaign against your own administrators. Under FedRAMP's Consolidated Rules for 2026, the control now reads simply "conduct penetration testing" at an organization-defined frequency, and is treated as part of vulnerability detection and response. Penetration testing applies from Class B upward; independent testing teams and red team exercises attach only to Classes C and D. If FedRAMP is your path, confirm the current expectation with your assessor rather than with an article — including this one.
SOC 2 — not required, but named in the framework, which is why it feels required. The trust services criteria are criteria, not a control list: you select the controls, and the auditor evaluates whether they meet the criteria. No specific control activity is mandated. But penetration testing is named in the framework, under CC4.1, as one of the evaluation types management may use — alongside vulnerability scans, internal audit assessments, and third-party assessments. Those are points of focus: illustrative, not compulsory. That distinction is the whole answer. A penetration test is one way to satisfy CC4.1, which asks you to perform evaluations "to ascertain whether the components of internal control are present and functioning." Skip it and the burden shifts to you to show what you did instead and why it was sufficient — which is a real burden, and the reason most companies simply buy the test. If the customer is asking for the SOC 2 report itself rather than a test, that is a separate question, and we worked through it in do you actually need SOC 2 to close an enterprise deal.
CMMC — depends on the level, and the timing is unusual right now. At Levels 1 and 2, no penetration test is required. The relevant Level 2 practice, CA.L2-3.12.1, requires you to "periodically assess the security controls in organizational systems to determine if the controls are effective in their application." Vulnerability scanning and system monitoring are described as activities that help maintain your security posture — useful, but not a substitute for the periodic assessment itself. Level 3 does call for testing: CA.L3-3.12.1e requires penetration testing at least annually or when significant security changes are made.
Level 3 assessments, however, are currently paused. The Department of Defense suspended the transition to CMMC Phase 2 in July 2026, and during the suspension new solicitations are limited to Level 1 (Self) and Level 2 (Self) assessments, with third-party Level 2 and Level 3 assessments on hold. What is not paused is the obligation. DFARS 252.204-7012 remains in force, and protecting controlled unclassified information — implementing NIST SP 800-171 and maintaining an accurate score in SPRS — is required exactly as it was before. The certification regime is on hold; the duty to safeguard CUI is not. If someone is selling you urgency about a Level 3 assessment this quarter, that distinction is the first thing to check.
Your customer's contract — often the real answer. None of the above matters if the master agreement or security addendum in front of you commits you to annual third-party testing. That is a contractual obligation whatever the frameworks say, and it is the one people skim past on the way to the pricing schedule. Read the clause, and have your counsel confirm what you are agreeing to before it is signed.
So the first move is not to collect quotes. It is to find out which of these situations you are actually in. If nobody on either side can point to the clause or the criterion driving the request, you may be looking at a preference rather than a requirement — and preferences can be discussed.
Three different things share the name
A vulnerability scan is automated. Tooling checks your systems against a database of known issues and produces a list. It is useful, it is inexpensive, and it should probably be running on a schedule regardless. It is not a penetration test.
A penetration test is a person attempting to exploit what they find, within an agreed scope and time window, documenting how far they got and how. The value is in the judgment — what chains together, what is genuinely reachable, what someone would actually do with it.
A red team exercise is broader and adversarial, testing detection and response as much as the systems themselves, usually without your defenders knowing. Almost nobody asking you for a "pen test" wants this, and it costs considerably more.
Spend some time reading what engineers say publicly about the tests they have bought, and one complaint dominates: they paid for the second and received the first. An automated scan, lightly reviewed, delivered as a PDF. Findings listed as outdated software versions with severity ratings copied straight from the scanner, and no demonstration that any of them are exploitable in your environment. That report will usually satisfy a checkbox. It will not tell you anything you could not have learned for a fraction of the price, and it will not survive contact with a customer's security team that reads it properly.
Questions to ask before you sign
You do not need to be technical to ask these. The answers separate the two kinds of vendor quickly.
- Who performs the test, and how many hours are budgeted? You want named people and an hour count. A proposal that describes a platform but never a person is selling you scanning.
- What methodology do you follow? Any real firm answers this immediately and specifically.
- What is in scope, and who decided? Scope should track what your customer is worried about — usually the product and the paths their data takes through it.
- Will findings include evidence and exploitability, or only severity ratings? "We found this, here is how we used it, here is what it exposed" is the deliverable worth paying for.
- Is a retest included after we remediate? Buyers care more about the fix than the finding, and under PCI the retest is explicitly required.
- Can I see a redacted sample report? Ask before you sign, not after.
- Will you provide a summary letter I can share with customers? You will need one. More on that below.
- Do you also sell the remediation work? Not disqualifying, but a firm that generates findings and then quotes you to fix them has an obvious incentive. Price the two separately.
A report is not a pass
There is no such thing as passing a penetration test. None of these frameworks issues a grade, a certificate, or an attestation for the test itself. What exists is a report, covering a defined scope, on a defined date, listing what the tester found.
What the frameworks judge is whether the test happened as specified and what you did with the findings. PCI DSS is the clearest case: exploitable vulnerabilities must be corrected and the test repeated to verify it, and an assessor will mark the requirement not in place if that has not happened. So "we passed our pen test" is not a thing that exists. "Our penetration test supported an in-place finding for Requirement 11.4" is. Be wary of any vendor selling you the first sentence.
Two practical points follow. First, do not forward the raw report to a customer without reading it closely. It may contain unresolved findings, internal hostnames, and detail you would rather not distribute — most firms will provide a summary or attestation letter for exactly this purpose, so ask for one when you scope the work, not after the deal is waiting. Second, what a reviewer actually wants is not a clean report. It is evidence that you found things, fixed them, and can show the retest. A report with findings and documented remediation reads better than a suspiciously empty one.
If it is a preference and the budget is not there
When the request is soft, the goal is to give the reviewer enough to record a defensible decision. In practice that means some combination of a tightly scoped external test against the product itself rather than everything you own; documented vulnerability scanning with a record of what you remediated and when; evidence of how security is handled in your development process; and a call between your senior security representative and theirs.
That last one is worth more than founders expect. Reviewers are not trying to fail you. They are trying to write down a decision they can defend later, and a competent conversation often gets them there.
One scheduling note: reputable firms book weeks out, and a test plus remediation plus retest is measured in months, not days. Do not commit to a date in a live deal before you have talked to a firm that can actually take the work.
Where this goes wrong most often
The expensive mistakes are consistent. Buying the cheapest quote, and receiving a scan. Letting the tester define the scope alone, and paying to test the wrong things. Treating the report as the finish line rather than the remediation. And committing contractually to annual third-party testing without pricing what that obligation costs every year from now on.
Choosing and overseeing this kind of vendor is part of what we do — scoping the work against what your customer actually asked for, reviewing what comes back, and making sure the findings turn into something you can show. If a customer has asked you for a test and you are not sure whether you need one, book a 30-minute deal-readiness call. If it arrived inside a larger questionnaire, Security Questionnaire Rescue starts at $1,500.
Written September 2026, citing PCI DSS v4.0.1, the 2017 Trust Services Criteria with revised points of focus, NIST SP 800-171 Revision 2 as CMMC currently references it, and FedRAMP's Consolidated Rules for 2026. Requirements in this area move; confirm the current position for your own situation before acting on it.