Penetration testing that supports compliance
Almost nobody buys a penetration test because they want one. They buy it because a customer, an auditor, a framework or a contract asked for additional assurance, and the report has to stand up to whoever asked.
A test that ends in a PDF nobody actions is an expense. A test whose findings become tracked work is evidence.
Send us the clause or the customer request. Thirty minutes and you will know what it actually calls for, what it will cost, and whether you need a test at all.
What usually triggers the request- A finding is identified
- It becomes a POA&M item
- Somebody owns it, with a date
- Remediation evidence is attached
- Closed, with a defensible record
What is actually asking you for penetration testing?
Penetration testing usually arrives attached to something else. Knowing which one is asking decides the scope, the timing, and sometimes whether you need a test at all. Here are the seven drivers we see, and what each one really requires.
Prime contractor flowdown
Read the clausePrimes frequently pass testing requirements down, sometimes ahead of what the regulation itself asks for. The clause decides the scope and the cadence. Send it to us and we will tell you what it actually calls for, which is often narrower than it reads.
NIST SP 800-172
Usually in scopeNIST SP 800-172 covers enhanced requirements for organizations facing advanced persistent threats. Testing and adversarial assessment feature far more prominently here than in NIST SP 800-171, and this is one of the clearer cases where penetration testing is genuinely expected.
SOC 2
Common, not mandatorySOC 2 does not name penetration testing as a requirement. Auditors commonly expect some form of testing as evidence of vulnerability management, and many customers ask for it directly, but the scope is a judgment call rather than a checkbox.
ISO/IEC 27001
Common, not mandatoryTechnical vulnerability management sits in Annex A. Penetration testing is one reasonable way to evidence it, not the only one. Scope it to what your risk assessment and Statement of Applicability actually justify.
A customer requirement
Read the requestThe most common driver of all, and the most negotiable. Customers often ask for a test when what they want is assurance. Sometimes a current report satisfies them; sometimes a well-evidenced vulnerability management program does.
CMMC Level 3
ExpectedLevel 3 builds on NIST SP 800-172 and is aimed at organizations supporting the most sensitive programs. If you are pursuing it, assume penetration testing is part of the picture and plan the calendar accordingly.
CMMC Level 2 / NIST SP 800-171
Not requiredNeither requires a penetration test. If someone has told you otherwise, check the source. It is one of the most common and most expensive misunderstandings in this market. You may still choose to test, but do it for a reason you can articulate.
Cyber insurance renewal
Read the formInsurers increasingly ask whether testing was performed in the last twelve months. The question is usually binary and the underwriter rarely reads the report, so a narrow, honest, well-scoped engagement answers it. Do not buy a wider test than the form asks for.
CMMC Level 2 and NIST SP 800-171 do not require penetration testing
Do not assume you need a test purely to satisfy Level 2. We would rather tell you that now than sell you one. Always evaluate the requirement against the applicable framework and the actual contract language, and if the clause is ambiguous, ask the party who wrote it before you spend anything. See what CMMC and NIST SP 800-171 do require.
Who tests what, and who never does
There is one rule we do not bend: Greypike does not test environments Greypike builds and operates. Both cases are below, so you can see exactly who performs the work in each.
Your own environment
Tested under a Greypike engagementEnvironments you own and run. We scope the penetration testing engagement, manage it, and bring the findings straight into your compliance program as tracked remediation work.
What we cover- Internal networks
- Cloud environments
- External attack surfaces
- Web applications
- Customer-hosted infrastructure
A Greypike Secure Enclave
Tested by an independent third partyWhen your Controlled Unclassified Information sits in an enclave we built and operate, we do not test it. An independent third party does, and the findings come back into your program the same way.
What stays the same for you- We scope and manage the engagement
- Findings land in your Compliance App
- Remediation becomes assigned work
- Evidence is retained in your program
- The report is independent, which is the point
Why we give the work away when it is our own environment
Testing something you built and operate is not a test, it is a self-assessment with a nicer cover page. Independent validation is stronger evidence for your customers, your auditors and your assessors, and it removes a conflict of interest that someone would eventually find and ask about.
What every penetration testing engagement includes
Written so two different audiences can both use it: the executive who has to decide, and the engineer who has to fix.
Executive summary
High-level findings and business impact, in language a board or a customer can read.
Technical findings
Detailed descriptions of the vulnerabilities and weaknesses identified, with enough detail to reproduce.
Risk ratings
Prioritized by potential impact and likelihood, so the fix order is obvious.
Remediation guidance
Recommended actions for correcting each finding, not just a description of what is wrong.
Evidence package
Documentation suitable for customer reviews, compliance programs and audit support.
Retest option
Validation that identified issues have actually been addressed, where applicable.
The evidence package is the part most buyers do not think to ask about and later wish they had. A penetration testing report written only for engineers fails the moment a customer’s procurement team or an assessor asks what you did about it. Both audiences get what they need, in the same deliverable.
Not sure whether you actually need a test?
Send us the clause, the questionnaire or the customer email. We will tell you what it calls for, what the scope should be, and how much of it you already satisfy another way. Including when the answer is that no penetration testing is required at all.
Most penetration test reports are read once and forgotten
A finding that nobody owns is not remediated, and a PDF on a file share is not evidence. Greypike imports penetration testing findings into the Compliance App as remediation work with an owner, a date and a definition of done. Here is what that looks like.
Legacy VPN appliance missing vendor patches
Service account with excessive privileges
TLS configuration permits deprecated ciphers
Three findings, three owners, three dates. Nothing is waiting on somebody remembering to open the PDF.
This is also what makes a retest worth buying. A retest against an untracked report means someone reconstructing from memory which of last year’s findings were ever addressed. A retest against tracked work is a confirmation pass on a list that already has dates and evidence attached to it.
What penetration testing does not cover
A test evaluates technical security controls within the defined scope. Plenty of compliance obligations sit outside that scope entirely, and a report is not evidence that they are handled.
These usually stay with you, your MSP or your facilities team
Penetration testing is one component of a broader program, not a substitute for the rest of it. We would rather set that expectation now than have it surface during an assessment.
- Physical security controls
- Facility security
- Visitor management
- Hardware custody
- Media protection procedures
- Asset disposal processes
All of these are tracked in the Compliance App as assigned work with owners and evidence. They are just not something a tester can validate from the network.
Why organizations choose Greypike for penetration testing
Not because we test differently. Because of what happens to the findings afterwards.
- Veteran-Owned Small Business
- 20+ years across government and the Defense Industrial Base
- 20+ DIB contractors on active contracts supporting defense missions
- 14 years as a cybersecurity and fraud investigator
- Cyber AB Registered Practitioner (RP) and Registered Practitioner Advanced (RPA) on the team
- MIT Sloan certificate in artificial intelligence for business strategy and governance
Why this page tells you when not to buy
Penetration testing is one of the easiest things in this market to oversell. The requirement is usually vague, the buyer is usually under pressure from someone else, and almost nobody reads the framework text themselves. A vendor who wants the sale has every incentive to let “CMMC requires a pen test” go uncorrected.
Fourteen years investigating cybersecurity and fraud cases is a reasonable education in what happens when nobody checks the claim. Two decades in the Defense Industrial Base is a reasonable education in what an assessor actually asks for. Between them, the honest answer to most of these questions is narrower than what gets quoted, and saying so costs us a few engagements and earns the ones that matter.
The engagements we do want are the ones where the finding chain is the point. If a test produces a report and nothing changes, you paid for a document. If it produces tracked work with owners, dates and evidence, you paid for a stronger compliance program that happens to have started with a test.
Penetration testing questions we get asked
Does CMMC require a penetration test?
Not at Level 2. Neither CMMC Level 2 nor NIST SP 800-171 requires penetration testing, and this is one of the most common and most expensive misunderstandings in the defense market. CMMC Level 3 builds on NIST SP 800-172, where testing and adversarial assessment feature far more prominently, so at Level 3 you should assume it is part of the picture. If someone has told you a test is mandatory for Level 2, check the source before you spend anything.
Does SOC 2 or ISO 27001 require penetration testing?
Neither names it as a requirement. SOC 2 auditors commonly expect some form of testing as evidence of vulnerability management, and many customers ask for it directly, but the scope is a judgment call. For ISO/IEC 27001, technical vulnerability management sits in Annex A and a penetration test is one reasonable way to evidence it rather than the only one. Scope it to what your risk assessment and Statement of Applicability actually justify.
Will Greypike test an environment Greypike built?
No. If your Controlled Unclassified Information sits in a Greypike Secure Enclave that we built and operate, an independent third party performs the penetration testing. Testing something you built and operate is a self-assessment with a nicer cover page. Independent validation is stronger evidence for your customers, your auditors and your assessors, and it removes a conflict of interest that someone would eventually find and ask about. We still scope and manage the engagement, and the findings come back into your program the same way.
What happens to the findings after the test?
Each one becomes tracked remediation work. A finding is imported into the Compliance App as a POA&M item or a remediation task, assigned to a named owner with a due date, evidenced when the fix is in place, and closed with a defensible record. That chain is what makes the report hold up later. A finding nobody owns is not remediated, and a PDF on a file share is not evidence.
What do you actually test?
For customer-managed environments: internal networks, cloud environments, external attack surfaces, web applications and customer-hosted infrastructure. The exact scope is set by whatever is driving the requirement, which is why we ask for the clause or the customer request first. A test scoped to the catalog rather than to the requirement costs more and proves less.
What is in the report?
Six things: an executive summary in language a board or a customer can read, detailed technical findings with enough information to reproduce, risk ratings prioritized by impact and likelihood, remediation guidance rather than just a description of what is wrong, an evidence package suitable for customer reviews and audit support, and a retest option where applicable.
What does a penetration test not cover?
A test evaluates technical security controls within the defined scope. Physical security controls, facility security, visitor management, hardware custody, media protection procedures and asset disposal all sit outside it, and a report is not evidence that they are handled. Those obligations stay with you, your MSP or your facilities team, and they are tracked in the Compliance App as assigned work with owners and evidence.
How much does penetration testing cost?
It is scoped and priced on requirements rather than sold as a package, because the honest range depends entirely on what is being tested and why. The fastest way to an accurate number is to send us the clause, the questionnaire or the customer request. Frequently the scope that satisfies the requirement is narrower than the one that gets quoted, and occasionally the answer is that you do not need a test at all.
Last reviewed: September 2026
Scoped against the requirement, not the catalog
Whether it is SOC 2, ISO/IEC 27001, NIST SP 800-172, a customer security review or an advanced contracting requirement, send us the clause and we will tell you what it actually calls for. Including if the answer is that you do not need a test.
Independent testing · Findings become tracked work · Evidence that holds up
