Quick answer: all three platforms treat a penetration test as recommended rather than mandatory, and all three take the report as manual upload evidence that no integration can produce for you. Vanta states that "performing a pen test or having a bug bounty program is not a hard requirement, but you must show good technical vulnerability management", and that "Vanta (and auditors) recommends conducting an annual external pen test". Drata carries a named control, DCF-19 Penetration Test, and tells you to "upload evidence of the most recent penetration testing activities", specifically report or reports "showing scope and results of the assessment, evidence of the internal tracking and remediation of findings". Secureframe says a pen test "is not necessarily a hard pass/fail control requirement as it relates to SOC 2", then adds the sentence that settles most vendor arguments: "all auditors will accept a pen test report as evidence".
The cadence all three publish is annual. The timing rule that actually catches teams is Secureframe's split: for a SOC 2 Type 1, the test "can have taken place anytime in the prior 12 months from the report date"; for a Type 2, it "has to occur during the audit period".
Every quotation on this page was read from the platform's own help centre or documentation on 5 September 2026 and links back to the page it came from. Where the three platforms disagree, this page says so rather than blending them into an average.
The check, platform by platform
Platform | Where the check lives | What the platform calls it | Evidence it accepts | Published cadence | Platform's own position on whether it is mandatory |
|---|---|---|---|---|---|
Vanta | Documents page, surfaced on the Monitors (Tests) page as a document test | No public control identifier; documented as a document requiring upload | An uploaded file. Vanta's supported types are ".ai, .csv, .docx, .jpg, .pdf, .png, .txt, .webp, .xlsx, and .zip", with a 50 MB cap. Penetration tests are uploaded on the Documents page | Renewal recurrence is configurable: Annually, Bi-annually, Quarterly, Monthly, Weekly or Never. Vanta recommends an annual external pen test | "Performing a pen test or having a bug bounty program is not a hard requirement, but you must show good technical vulnerability management" |
Drata | Controls, as a not monitored control requiring uploaded evidence | DCF-19, Penetration Test (SOC 2 and HIPAA evidence tables) and DCF-19, Penetration Tests (ISO 27001 table) | "Report(s) of the most recent penetration test(s) performed by a third-party or internal resource showing scope and results of the assessment, evidence of the internal tracking and remediation of findings (internal tickets, change documentation)" | ISO 27001 guidance states penetration tests "should be conducted at least annually or after significant changes to the environment". HIPAA guidance asks for the "most recently completed annual penetration test" | On SOC 2 specifically, Drata's answer to whether penetration tests are required is "No, they are not" |
Secureframe | Tests page, as an upload test with a configurable interval | "Penetration testing" test, listed under the annual items for a SOC 2 Type 2 window | An uploaded pen test report. Upload tests "require you to upload a file as evidence" and remain failing without one | "Penetration tests are required at least annually and should be done by an external provider." External testing "should be performed at least once every 12 months" | "Though performing a pen test is highly recommended, it is not necessarily a hard pass/fail control requirement as it relates to SOC 2" |
Three practical consequences fall out of that table.
No integration can close this check. Every other control in these platforms trends toward automation: cloud configuration, MFA enforcement, branch protection, endpoint encryption. A penetration test is an event that happened to your systems, performed by people and tools outside the platform's field of view, so all three fall back to a human uploading a file. That is why the pentest row is the one still red the week before fieldwork.
The platform is not the auditor. Secureframe says this outright: "Each auditor sets their own individual requirements regarding the activities needed to satisfy this control." A green check in a compliance platform is a project-management signal, not an audit opinion. The auditor decides whether your evidence is sufficient, and the platform simply carries it.
Annual is the platforms' recommendation, not a framework rule. The 2017 Trust Services Criteria contain no cadence at all. Search the AICPA's Trust Services Criteria for "annual", "annually", "quarterly", "semiannual" or "at least once" and you get zero hits. The annual rhythm you are being held to came from your own control description, your ISMS policy, a customer contract or the platform's recommendation, in roughly that order of frequency. Our companion piece on what auditors actually accept as pentest evidence traces each framework back to its clause.
Vanta: a document test, and the vulnerability management bar behind it
Vanta's position is the most explicit of the three, and it is worth reading twice because it is routinely misquoted in the other direction.
"Performing a pen test or having a bug bounty program is not a hard requirement, but you must show good technical vulnerability management. In other words, there needs to be a tool in place for external vulnerability scanning (a pen test or bug bounty program would cover this). Your auditor will want evidence of a vulnerability scanning tool and that you are remediating any detected vulnerabilities within your SLAs."
Two things follow. First, the underlying obligation is vulnerability management with SLAs, not a penetration test. Second, a penetration test is one of two named ways to satisfy the external scanning leg, and Vanta says the two are alternatives: "If you already conduct annual pen tests, you do not need to put a bug bounty program in place (and vice versa)."
Vanta's scanning guidance sets the surrounding cadence. Its SOC 2 control language reads "Host-based vulnerability scans are performed at least quarterly on all external-facing systems. Critical and high vulnerabilities are tracked for remediation", and the practical evidence bar is "evidence that a vulnerability scan was conducted within the past quarter" plus "a sample of vulnerabilities was remediated within a customer-defined SLA". Vanta then notes that a penetration test can double as that scan evidence for some auditors, because a test typically involves running a scan against host environments.
How the evidence actually lands. Vanta calls these document tests: "some tests require you to upload a document as evidence... When you upload or edit a document for a test, it appears both on the Monitors (Tests) page and the Documents page." Penetration tests go there: "Customers can upload recent penetration tests on the Documents pages."
The status model is where teams get surprised. Vanta's own table maps document state to compliance state:
Vanta document status | Test status | Compliance status | What it means |
|---|---|---|---|
OK | OK | Passing | A non-expired file exists in the document container |
Needs update | Due soon | Passing | The document is nearing expiration within the reminder window |
Needs document | Needs remediation | Failing | No files have ever been uploaded |
Needs document | Overdue | Failing | There are only expired files uploaded |
Not relevant | Not relevant | Deactivated | Deactivated or ignored for the standard by an auditor |
Note the fourth row. An expired report is treated exactly like no report. The renewal clock is also not the clock most people assume: "The next renewal is calculated from the effective date of the uploaded file(s), not the date the document was renewed." Upload a report dated eleven months ago and you have bought yourself one month, not twelve. Renewal recurrence is selectable from Annually, Bi-annually, Quarterly, Monthly, Weekly or Never.
Audit-window discipline. Vanta's audit readiness checklist tells you to start the review "at least 2 to 4 weeks before your target audit start date", and its rules for the observation window include "Do not alter uploaded documents during the observation window without auditor approval." It also flags the testing question directly: "Depending on your audit type, your auditor may also request a penetration test. For example, some PCI levels require one, and many SOC 2 auditors consider it a best practice."
Drata: DCF-19, and the remediation loop attached to it
Drata is the only one of the three with a stable, public control identifier for penetration testing, which makes it the easiest to scope against. DCF-19 appears in Drata's SOC 2, ISO 27001 and HIPAA evidence guidance, and the SOC 2 entry reads:
"Upload evidence of the most recent penetration testing activities. Example: Report(s) of the most recent penetration test(s) performed by a third-party or internal resource showing scope and results of the assessment, evidence of the internal tracking and remediation of findings (internal tickets, change documentation), etc."
Three requirements are packed into that sentence, and only the first is the report.
Scope and results. The report must show what was in scope, not only what was found. A findings list without a documented scope leaves the auditor unable to tell whether the systems in your SOC 2 boundary were covered.
Internal tracking. Tickets, change documentation, a remediation log. Drata is asking you to prove the findings entered your normal engineering workflow rather than sitting in a PDF.
A defensible position on everything still open. Drata's guidance says auditors evaluate the testing activity against your own policy requirements, giving two examples: documented justification for vulnerabilities the testers found that you accepted as risks or deemed non-exploitable, and exploitable vulnerabilities resolved within company-defined SLAs.
That third point is the one that converts a pentest from a purchase into a programme. If your vulnerability management policy says Criticals close in 14 days and your report shows a Critical open at 60 days with no risk acceptance memo, the control fails on your own policy rather than on any framework text.
Drata's ISO 27001 entry adds the change trigger. The same control, listed as DCF-19 Penetration Tests, carries an explicit cadence line: "Penetration tests should be conducted at least annually or after significant changes to the environment." Drata's ISO guidance also asks, under its control for audit activities, for "screenshots or exports of communications and agreements with penetration tests vendors discussing and agreeing on the scope of the test, access requirements, availability considerations". Keep the scoping thread with your provider. It is evidence.
Drata's HIPAA entry is the terse one: "Most recently completed annual penetration test."
On SOC 2 itself, Drata is unambiguous. Asked whether penetration tests are required for SOC 2 compliance, Drata answers "No, they are not", and ties the practice to criterion CC4.1, quoting it as "The entity selects, develops, and performs ongoing and/or separate evaluations to ascertain whether the components of internal control are present and functioning." Drata then reproduces the AICPA's menu of evaluations that may satisfy that criterion, which includes vulnerability scans, internal audit assessments, compliance assessments, security assessment, penetration testing and third-party assessments. A penetration test is one item on a list of eight, not the list.
Secureframe: an upload test, with the clearest timing rule of the three
Secureframe publishes the most operationally useful guidance of the three, because it answers the question buyers actually have: when does the test need to happen?
"SOC 2 Type 1: Pen test can have taken place anytime in the prior 12 months from the report date." "SOC 2 Type 2: Pen test has to occur during the audit period."
That single distinction resolves most of the confusion in this topic, and it is the reason a company moving from a Type 1 to a Type 2 often needs a second test sooner than it budgeted for. Our deep dive on SOC 2 Type 2 penetration testing timing works through where in a 3 to 12 month observation window the test belongs.
Secureframe's recommendation is broader in scope than the other two: "an annual third-party penetration test of their internal and external environments and web applications". Its vulnerability management FAQ then sets the floor at "external penetration testing should be performed at least once every 12 months", allows internal delivery ("Can a penetration test be conducted internally? Yes, that's fine"), and describes the minimum scope as "the application should be in scope, and it's recommended to include the network (IP addresses)".
There is a genuine internal tension in Secureframe's own documentation worth naming rather than papering over. Its Type 2 preparation article says penetration tests "should be done by an external provider", while its vulnerability management FAQ says internal testing is fine. The reconciliation is that a third party is the recommendation and internal testing is the fallback the platform will not block, with the auditor as tiebreak.
Where Secureframe is blunter than the others. Its SOC 2 FAQ answers "Is a pen test required for SOC 2?" with "Generally, yes. Pen tests are required for SOC 2 Type 2 unless the environment is closed and robust vulnerability scanning is in place." That is a stronger statement than either Vanta's or Drata's, and it is a statement about auditor practice rather than about the Trust Services Criteria. Both things can be true: the criteria mandate nothing, and the market has converged on testing anyway.
Two mechanics to plan around. First, Secureframe upload tests carry an interval, a completion date and a due date, and "when the next due date on an upload test passes, Secureframe's daily evaluation job will automatically archive the existing evidence and move the test to a failing state". The next due date is calculated from the activity completion date plus the interval, so, as in Vanta, the date on the report is what starts the clock. Second, and easy to miss: "Evidence with findings noted will not pass the upload tests." If a reviewer annotates your uploaded report with a finding, the test stays red until that is resolved.
On non-production scope, Secureframe permits it conditionally: a test in a UAT environment is acceptable "as long as the UAT environment accurately mirrors production in security-relevant ways". Get that agreement from your auditor in writing before you scope against a staging environment.
Where the three platforms disagree, and what to do about it
Question | Vanta | Drata | Secureframe |
|---|---|---|---|
Is a penetration test mandatory? | Not a hard requirement | Not required for SOC 2 | Not a hard pass or fail control, but "generally, yes" for a Type 2 in practice |
Recommended cadence | Annual external test | At least annually, or after significant environment changes | At least annually, at least once every 12 months for external |
Third party or internal? | Recommends external | Accepts "a third-party or internal resource" | Recommends external, states internal is acceptable |
Is remediation evidence part of the check? | Not stated for the pentest document specifically; the vulnerability programme requires SLA-based remediation evidence | Yes, explicitly: internal tracking and remediation of findings | Not stated in the check itself; states auditors care about timely remediation more than about the findings |
What fails the check? | No file, or only expired files | No uploaded evidence for the control | No evidence, expired evidence, or evidence with findings noted |
The safe read across all three is the strictest read: an external test performed within the last 12 months, inside the observation window if you are running a Type 2, with a documented scope, tracked remediation, and a written position on anything left open. That bundle satisfies every one of the three platforms and every auditor position quoted on this page.
The evidence bundle that closes the check
A penetration test produces more than one artefact, and different audiences get different ones. Assembling the bundle up front is the difference between a check that turns green in an afternoon and a two-week chase during fieldwork.
1. The scope of work. A dated document naming the applications, domains, IP ranges, user roles and test types in scope, agreed before testing started. Drata asks for the scoping correspondence itself under its ISO 27001 guidance. This is the artefact most often missing, because it feels like paperwork rather than evidence.
2. The full technical report. Findings with severity, evidence, reproduction steps and remediation guidance. This is the engineering document. It is also the document you should be most careful about circulating, because it is a map of how to attack you.
3. Remediation tracking. Ticket identifiers, open and close dates, and the link from each finding to the change that fixed it. Drata names this explicitly. Secureframe's position is that "remediation in a timely manner is what auditors care about, not necessarily the actual findings".
4. Retest verification. Written confirmation that the fixes hold. A closed ticket is a claim; a retest is evidence. Retesting is the single most common gap between what a buyer thought they bought and what the auditor asks for.
5. A shareable completion letter. A one-page document confirming that a qualified firm assessed a defined scope over defined dates, with the overall risk position and no exploitable detail. This is what goes to customers, prospects and, in many cases, the auditor, while the full report stays internal. Our guide to the pentest completion letter versus the full report covers what belongs in each.
What a compliant attestation letter contains
Ask for these elements by name when you commission the test, because a letter written after the fact is always thinner than one scoped in from the start:
The testing firm's legal name, and any firm-level accreditation it holds as a penetration testing service provider.
The client entity name, matching the legal entity in your audit scope.
The scope, stated precisely enough for an auditor to reconcile against your system boundary: named applications, environments, network ranges, and whether testing was black box, grey box or white box.
The testing window, with start and end dates. This is the field that decides whether the letter falls inside a Type 2 observation period.
The methodology, named rather than described: OWASP Testing Guide, PTES, or the firm's documented approach.
A summary risk position, stating the severity distribution or the overall posture without listing exploitable detail.
The remediation and retest status as of the letter's date, including whether High and Critical findings were verified as resolved.
A named signatory with a role and a date.
Deliberately absent: reproduction steps, payloads, screenshots of exploited sessions, credentials, or anything a reader could act on. A letter that contains those things is not a letter, it is a redacted report, and it should not be circulated to customers.
Why the fix window matters more than the test date
The check is not really about a report. It is about whether findings get closed, and that is where the calendar bites.
Stingrai's State of Penetration Testing 2026 analysed 1,206 verified findings from 55 penetration tests. 92.7% of tests surfaced at least one High or Critical finding, which means the realistic planning assumption is not "we might find something" but "we will find something that has to be tracked, fixed and retested before fieldwork". Across findings with a tracked resolution time, the median Critical took 10.5 days to close, against 38.0 days for Highs. Highs are the schedule risk, not Criticals: Criticals get emergency attention, Highs get queued. The dataset also carried a 0.74% false-positive rate, which matters here because every disputed finding is a conversation you have to document for the auditor rather than simply close.
Read those two numbers against Drata's requirement for internal tracking and Secureframe's line about timely remediation, and the scheduling conclusion writes itself. If your Highs take five weeks to close and your retest needs to land inside the observation window, the test cannot be the last thing you book before fieldwork.
Mistakes that leave the check red
Uploading a report dated last year on the day you start the audit. Both Vanta and Secureframe compute the next due date from the date the activity was completed, not the date you uploaded the file. An old report can be expired the moment it lands.
Testing a scope narrower than your audit boundary. The auditor reconciles the two. A report covering one application when three are in the SOC 2 system description is a finding, not evidence.
Treating the report as the whole deliverable. Drata asks for tracking and remediation evidence in the same breath as the report. Secureframe's upload tests fail if a reviewer notes findings on the evidence.
Buying a test without a retest. Retesting is what converts a finding into a closed loop. If it is not in the statement of work, it becomes a change order at the worst possible moment.
Booking the test late in a Type 2 window. Secureframe is explicit that a Type 2 test has to occur during the audit period. Booking it in month eleven leaves no room to fix and reverify.
Sending the full technical report to customers. Use the completion letter. The report is an attack map.
Assuming the platform speaks for the auditor. Secureframe says each auditor sets their own requirements. Confirm the evidence expectation with the auditor before you scope, not after.
Letting a UAT environment stand in for production without written agreement. Secureframe allows it conditionally. Your auditor may not.
How Stingrai fits
Stingrai is an offensive security firm founded in 2021, headquartered in Toronto with a London office. We are a CREST-accredited penetration testing service provider at firm level, our team has published 18 CVEs, and we hold 5.0 out of 5.0 across 19 Clutch reviews.
Our penetration testing supports your SOC 2, ISO 27001, HIPAA and PCI DSS compliance programme by producing the artefacts these platforms ask for. In practice that means a scope of work delivered as its own dated document, a full technical report, remediation tracking that maps finding to ticket to change, retesting written into the engagement rather than sold afterwards, and a shareable completion letter our clients upload as evidence in Vanta, Drata and Secureframe. Reports and letters from Stingrai engagements are used as evidence in those platforms; the compliance opinion itself is your auditor's.
We deliver both one-time annual penetration tests and continuous testing programmes, which matters here because the two map onto different platform cadences. An annual engagement closes a yearly document test cleanly. A continuous programme gives you in-window evidence throughout a Type 2 observation period and fresh evidence after every significant environment change, which is exactly the trigger Drata's ISO 27001 guidance names.
Snipe, our autonomous web application testing agent, works alongside our penetration testers throughout an engagement rather than in front of them. Snipe is custom-trained on more than 6,000 HackerOne Hacktivity disclosure reports and on skills distilled from our own testers' methodology, so it hunts the complex authorization, IDOR and business logic flaws that scanners miss, performs both black box and white box testing, and can generate AutoFix pull requests and gate merges. Our testers direct where it looks and extend the attack paths it opens, and both contribute findings across every severity.
Published pricing is on the Stingrai pricing page: the Autonomous Pentest from US$3,000 one-time and the Hybrid Pentest at US$6,800 one-time, both covering one web application and its APIs, and the same two tiers continuously at US$450 and US$1,275 per month on a 12-month engagement. The Autonomous tier carries a published No High or Critical Finding, Don't Pay guarantee. For a scope larger than one application, request a quote and the number comes back scoped.
Frequently Asked Questions
Does Vanta require a penetration test?
No. Vanta states that "performing a pen test or having a bug bounty program is not a hard requirement, but you must show good technical vulnerability management", and that a pen test and a bug bounty program are alternatives rather than both being needed. What Vanta does require is evidence of external vulnerability scanning and of remediation within your own SLAs. Vanta then recommends an annual external pen test as "a reasonably easy control to implement", and its audit readiness checklist notes that depending on your audit type your auditor may request one. See Vanta's own answer.
What is Drata DCF-19?
DCF-19 is Drata's penetration testing control, and it appears in Drata's SOC 2, ISO 27001 and HIPAA evidence guidance. The instruction is to "upload evidence of the most recent penetration testing activities", with the example given as reports of the most recent penetration tests "performed by a third-party or internal resource showing scope and results of the assessment, evidence of the internal tracking and remediation of findings (internal tickets, change documentation)". Drata's ISO 27001 entry adds the cadence: at least annually or after significant changes to the environment. See Drata's evidence guidance.
What evidence does Secureframe accept for a penetration test?
An uploaded penetration test report, submitted against Secureframe's penetration testing upload test. Secureframe recommends "an annual third-party penetration test of their internal and external environments and web applications", states that "all auditors will accept a pen test report as evidence", and sets the external cadence at "at least once every 12 months". Two mechanics matter: the next due date is calculated from the activity completion date plus the test interval, and "evidence with findings noted will not pass the upload tests". See Secureframe's pen testing requirements.
When does the penetration test need to happen for a SOC 2 audit?
It depends on the report type, and Secureframe states the rule plainly: for a SOC 2 Type 1 the test "can have taken place anytime in the prior 12 months from the report date", while for a SOC 2 Type 2 it "has to occur during the audit period". Practically, that means a Type 2 test belongs early in the observation window so there is room to remediate and retest before fieldwork. Our guide to SOC 2 Type 2 penetration testing timing sets that out as a month-by-month calendar.
Can I use an internal team instead of an external penetration testing provider?
All three platforms allow it, and all three prefer an external provider. Drata's DCF-19 example accepts a report from "a third-party or internal resource". Secureframe answers "Can a penetration test be conducted internally? Yes, that's fine" in its vulnerability management FAQ, while its Type 2 preparation article says tests "should be done by an external provider". Vanta recommends an annual external pen test. The deciding vote is your auditor's, and independence from the team that builds and runs the systems is what they are actually assessing.
Do these platforms have penetration testing partners?
Vanta and Secureframe both operate partner introduction programmes and route requests through their support teams rather than publishing an open partner list, and Secureframe's categories include web application and network penetration testing providers. Being on a partner list is not a compliance requirement. What matters to the check is the evidence quality: a documented scope, a report that maps to your audit boundary, tracked remediation and a retest.
How often do I need to run a penetration test to keep the check green?
Annually is the cadence all three platforms publish, and Drata's ISO 27001 guidance adds "or after significant changes to the environment". Beyond the calendar, the platform mechanics enforce their own clock: Vanta's document test fails when "there are only expired files uploaded", and Secureframe's daily evaluation job archives evidence and fails the test once the due date passes. Our guide to how often you should run a penetration test covers cadence by framework and by change rate.
What is a pentest attestation letter and do I need one?
It is a one-page document confirming that a qualified firm tested a defined scope over defined dates, stating the overall risk position without exploitable detail. You need one if customers, prospects or procurement teams ask for proof of testing, because the full technical report is an attack map and should not circulate. A good letter names the testing firm and any firm-level accreditation, the client entity, the scope, the test window, the methodology, the summary risk position, remediation and retest status, and a named signatory. See pentest completion letter versus full report.
Does a vulnerability scan satisfy the penetration testing check?
Sometimes, and only for the scanning control rather than for the testing control. Vanta notes that penetration tests typically involve running a vulnerability scan against host environments, so "these are accepted by some auditors" as scan evidence, which is the relationship running in the opposite direction. Secureframe's position is that the required thing is "a comprehensive vulnerability assessment program", with a pen test as the most commonly accepted way to demonstrate it. Our comparison of penetration testing and vulnerability assessment covers what each one evidences.
Can I run the test against a staging environment instead of production?
Secureframe says yes conditionally: a SOC 2 penetration test can be performed in a UAT rather than production environment "as long as the UAT environment accurately mirrors production in security-relevant ways", including the same infrastructure configuration. Get that agreement from your auditor in writing before you scope. Where the staging environment differs from production in authentication, network exposure or data handling, the test result does not transfer.
What happens to the check if the test finds Critical vulnerabilities?
Nothing bad, provided you track and close them. Secureframe's position is that there are no penalties for finding vulnerabilities and that "remediation in a timely manner is what auditors care about, not necessarily the actual findings". Drata's guidance says auditors evaluate the testing activity against your own policy requirements, expecting exploitable vulnerabilities resolved within company-defined SLAs and documented justification for anything accepted as a risk. The audit exposure comes from untracked findings and missed SLAs, not from the existence of findings.
Does uploading a report to one platform satisfy another?
Yes, as an artefact. The same report, scope of work, remediation log and retest evidence satisfy Vanta's document test, Drata's DCF-19 and Secureframe's upload test, because all three are asking for the same underlying facts in different containers. What does not transfer is the cadence configuration and the audit context: each platform computes its own due date from the completion date and the interval you set, and each audit has its own scope boundary to reconcile against.
Related reading
SOC 2 Type 2 penetration testing timing, where the test belongs in the observation window and what auditors ask for.
SOC 2 penetration testing in 2026, the scoping and control-description guide.
Pentest evidence auditors accept: SOC 2, ISO 27001, PCI DSS and CMMC, the clause-level source of every cadence claim.
Pentest completion letter versus full report, what to share with customers and auditors.
How often should you do penetration testing?, cadence by framework, change rate and risk.
How to prepare for a SOC 2 audit, the wider readiness checklist.
How to scope a penetration test, the mechanics behind the scope of work document.
References
Vanta. Frequently Asked Question: Are Penetration tests and Bug Bounty Programs Required for my Audit? Article dated 16 October 2025, retrieved 5 September 2026. https://help.vanta.com/en/articles/11346117-frequently-asked-question-are-penetration-tests-and-bug-bounty-programs-required-for-my-audit. Vanta's position that a pen test is not a hard requirement, and its annual external testing recommendation.
Vanta. Penetration Testing. Article dated 16 October 2025, retrieved 5 September 2026. https://help.vanta.com/en/articles/12511759-penetration-testing. Vanta's process model, ending in remediation and retesting, and its list of frameworks that expect periodic testing.
Vanta. Managing Documents. Retrieved 5 September 2026. https://help.vanta.com/en/articles/11345479-managing-documents. Document tests, the document status to compliance status mapping, supported file types and the 50 MB upload cap.
Vanta. Document Renewal Settings. Retrieved 5 September 2026. https://help.vanta.com/en/articles/11345476-document-renewal-settings. Renewal recurrence options and the rule that renewal is calculated from the effective date of the uploaded file.
Vanta. Frequently Asked Question: What Should I Use for Vulnerability Scanning? Retrieved 5 September 2026. https://help.vanta.com/en/articles/11346112-frequently-asked-question-what-should-i-use-for-vulnerability-scanning. Quarterly scan evidence expectation, the SOC 2 control language, and the note that penetration tests are uploaded on the Documents page.
Vanta. Audit 103: The Audit Readiness Checklist. Retrieved 5 September 2026. https://help.vanta.com/en/articles/11345845-audit-103-the-audit-readiness-checklist. Pre-audit timing, observation window rules, and the note that an auditor may request a penetration test.
Drata. Example Evidence for Not Monitored Controls (SOC 2). Retrieved 5 September 2026. https://help.drata.com/en/articles/9421165-example-evidence-for-not-monitored-controls-soc-2. DCF-19 Penetration Test, the evidence example, and what auditors evaluate the activity against.
Drata. Example Evidence for Not Monitored Controls (ISO 27001). Retrieved 5 September 2026. https://help.drata.com/en/articles/11895559-example-evidence-for-not-monitored-controls-iso-27001-revised-following-5-7-2024-updates. The at least annually or after significant change cadence, and the scoping correspondence evidence.
Drata. Example Evidence for Not Monitored Controls (HIPAA). Retrieved 5 September 2026. https://help.drata.com/en/articles/9421032-example-evidence-for-not-monitored-controls-hipaa. The most recently completed annual penetration test.
Drata. Penetration Tests and SOC 2: Preference, Tradition, or Requirement? Retrieved 5 September 2026. https://drata.com/learn/soc-2/penetration-tests. Drata's answer that penetration tests are not required for SOC 2, and the CC4.1 quotation.
Secureframe. Pen Testing Requirements. Retrieved 5 September 2026. https://support.secureframe.com/en/articles/15111430-pen-testing-requirements. The annual third-party recommendation, the not a hard pass or fail statement, and the Type 1 versus Type 2 timing rule.
Secureframe. Preparing for a SOC 2, Type 2 Audit. Retrieved 5 September 2026. https://support.secureframe.com/en/articles/15111418-preparing-for-a-soc-2-type-2-audit. Penetration tests required at least annually and delivered by an external provider, alongside the wider Type 2 population list.
Secureframe. SOC 2 Type 2 Audit Review Period Items. Retrieved 5 September 2026. https://support.secureframe.com/en/articles/15111466-soc-2-type-2-audit-review-period-items. Penetration testing listed among annual items, and the evidence rule for annual controls inside a Type 2 window.
Secureframe. FAQs: Vulnerability management: scanning, remediation, and evidence. Retrieved 5 September 2026. https://support.secureframe.com/en/articles/15111314-faqs-vulnerability-management-scanning-remediation-and-evidence. External testing every 12 months, internal testing permitted, baseline scope, and the position on remediation timeliness.
Secureframe. FAQs: SOC 2: audits, trust services criteria, and common scenarios. Retrieved 5 September 2026. https://support.secureframe.com/en/articles/15111447-faqs-soc-2-audits-trust-services-criteria-and-common-scenarios. The generally yes answer for Type 2, the UAT environment allowance, and the automatic failure of an upload test once its due date passes.
Secureframe. Tests Page Overview: Test Types, Uploading Evidence, Filtering. Retrieved 5 September 2026. https://support.secureframe.com/en/articles/15111248-tests-page-overview-test-types-uploading-evidence-filtering. Upload test definition and the rule that evidence with findings noted does not pass.
AICPA and CIMA. 2017 Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy (With Revised Points of Focus, 2022). Retrieved 5 September 2026. https://www.aicpa-cima.com/resources/download/2017-trust-services-criteria-with-revised-points-of-focus-2022. Criterion CC4.1, the point of focus that names penetration testing, and the absence of any testing cadence in the criteria.
Stingrai. The State of Penetration Testing 2026. https://www.stingrai.io/blog/state-of-penetration-testing-2026. 1,206 verified findings across 55 penetration tests, severity mix, remediation timing and false-positive rate.
Stingrai. Pricing. Retrieved 5 September 2026. https://www.stingrai.io/pricing. Published one-time and continuous package prices for one web application and its APIs.
