Quick answer: a SOC 2 Type 2 penetration test has to fall inside the observation window, and the right place for it is months three to five of a twelve-month window. Secureframe states the rule directly: for a "SOC 2 Type 1: Pen test can have taken place anytime in the prior 12 months from the report date", but for a "SOC 2 Type 2: Pen test has to occur during the audit period". The month three to five recommendation is arithmetic rather than taste. Across 1,206 verified findings from 55 penetration tests in Stingrai's State of Penetration Testing 2026, the median High finding took 38.0 days to close, so the fix-and-retest loop behind a report lands roughly two months after delivery. Test in month three and the loop closes by month five, with seven months of clean in-window evidence behind it.
What SOC 2 does not do is require the test at all. The strings "annual", "annually", "quarterly", "semiannual" and "at least once" appear zero times in the 2017 Trust Services Criteria. Penetration testing appears once, in a non-binding point of focus under CC4.1, on a list of eight evaluation types. Every cadence you are being held to came from your own control description, a customer contract or your compliance platform's recommendation.
This page is the timing companion to our broader guide on SOC 2 penetration testing, which covers scoping, control wording, mapping to the Common Criteria and cost. Every quotation here was read from the publisher's own document on 5 September 2026.
What the Trust Services Criteria actually say
Four criteria get cited in this conversation. Only two of them are load-bearing, and the two most often quoted are the wrong ones.
CC4.1 is the criterion a penetration test evidences. Its text reads: "COSO Principle 16: The entity selects, develops, and performs ongoing and/or separate evaluations to ascertain whether the components of internal control are present and functioning." A penetration test is a separate evaluation. So is an internal audit, a compliance assessment, a resilience assessment, a vulnerability scan, a security assessment, first- and second-line control testing, and a third-party assessment. The AICPA's point of focus lists all eight as things management's evaluations "may include". A menu is not a mandate.
CC4.2 is the criterion that actually bites. It reads: "COSO Principle 17: The entity evaluates and communicates internal control deficiencies in a timely manner to those parties responsible for taking corrective action, including senior management and the board of directors, as appropriate", with a point of focus stating that "Management tracks whether deficiencies are remedied on a timely basis". Once you elect a penetration test as your CC4.1 evaluation, its findings become deficiencies that CC4.2 pulls into a tracked, communicated remediation loop. That is why timing matters: an untracked or unclosed finding is worse audit exposure than never having tested.
CC7.1 is not the pentest criterion, and it is misquoted constantly. Its text is "To meet its objectives, the entity uses detection and monitoring procedures to identify (1) changes to configurations that result in the introduction of new vulnerabilities, and (2) susceptibilities to newly discovered vulnerabilities." Its relevant point of focus is titled "Conducts Vulnerability Scans" and describes infrastructure and software scanning "on a periodic basis and after any significant change in the environment". Scanning, not testing. If your auditor cites CC7.1, they want scan evidence.
CC7.2 is about anomaly detection, not testing at all. "The entity monitors system components and the operation of those components for anomalies that are indicative of malicious acts, natural disasters, and errors affecting the entity's ability to meet its objectives; anomalies are analyzed to determine whether they represent security events." It belongs to your logging, alerting and detection stack.
The practical read: your penetration test evidences CC4.1, your remediation trail evidences CC4.2, and your quarterly scans evidence CC7.1. Three different artefacts, three different cadences, one audit.
Type 1 versus Type 2: the difference that sets the deadline
The AICPA's attestation standards define the two report types, and the wording is the whole story. A type 1 report asserts that the system "was designed and implemented as of a specified date" and that controls "were suitably designed to achieve those control objectives as of the specified date". A type 2 report asserts that the system was "designed and implemented throughout the specified period", that controls were "suitably designed throughout the specified period", and that they "operated effectively throughout the specified period". That construct is defined in AT-C section 320, which governs SOC 1; SOC 2 examinations carry the same type 1 and type 2 terminology.
Two words do the work: as of against throughout.
SOC 2 Type 1 | SOC 2 Type 2 | |
|---|---|---|
What is being opined on | Design and implementation as of a single date | Design, implementation and operating effectiveness throughout a period |
When the penetration test may have happened | "Anytime in the prior 12 months from the report date" | "Has to occur during the audit period" |
Evidence character | A snapshot: the control existed and was designed appropriately | A population: the control operated repeatedly, or at its stated frequency, across the period |
Sample size for an annual control | One point-in-time artefact | A population of one, which is the trap below |
Where the risk sits | Getting the control description right | Getting the timing and the closed loop right |
The population-of-one problem. A control written as "we perform an annual penetration test" produces exactly one occurrence inside a twelve-month observation window. If that one occurrence is late, out of scope, or unretested, the auditor is not looking at a 10% exception rate. They are looking at 100%. There is no second sample to average against. This is the single sharpest reason to move the test early: an early test leaves room to fix a scoping mistake and test again inside the window, and a late test does not.
How long is the observation window, and who decides?
Nobody in the AICPA's published criteria sets a period length. Secureframe puts it plainly: "there is no SOC 2 requirement that forces companies to move directly from a 3-month to a 12-month observation window. The SOC 2 standard is flexible on observation periods, it only requires that the period be long enough to demonstrate operating effectiveness."
What exists instead is market practice, and Secureframe describes it: "most auditors follow industry best practice, which is to start with a shorter 3-month window (often in the first year) to establish a baseline, and then move to a 12-month window to demonstrate continuous compliance. Some firms might encourage or require this as part of their own methodology, not because the SOC 2 framework mandates it."
That produces three common shapes, and the penetration test sits differently in each.
Window length | Typical use | Where the penetration test goes | Why |
|---|---|---|---|
3 months | First Type 2, usually straight after a Type 1 | Before the window opens, or in the first three weeks | Secureframe's guidance for annual controls is that "you only need evidence at least once in the year prior to the end of the Type 2 window", so a test from shortly before a short window can still carry. Confirm with your auditor in writing |
6 months | Second cycle, or a customer-driven interim report | Month 1 to month 2 | A 38-day median fix cycle for Highs plus a retest needs roughly two months of runway inside the period |
12 months | Steady state | Month 3 to month 5 | Leaves a full fix-and-retest loop inside the window, plus five to seven months of clean evidence and room for a second test if scope changes |
One nuance worth carrying into the auditor conversation, because Secureframe's own documentation contains both halves. Its penetration testing article says a Type 2 test "has to occur during the audit period". Its Type 2 review-period article says that for annual and semi-annual controls "you only need evidence at least once in the year prior to the end of the Type 2 window", and lists penetration testing among the annual items. Those are reconcilable: the strict reading is the safe one, and the looser reading exists mainly to stop a company that just ran a test being forced to repeat it three months later for a short first window. Ask your auditor which reading they apply, and get the answer in writing before you book.
The twelve-month observation window, month by month
This is the calendar to run. Dates assume a window opening 1 January and closing 31 December, but the shape is what matters, not the months.
Period | What happens | Penetration testing action | Why this month |
|---|---|---|---|
Month minus 2 to minus 1 | Readiness: controls written, policies approved, integrations connected, scope agreed | Agree the test scope against the draft system description. Book the engagement | Vanta's readiness guidance is to start the pre-audit review "at least 2 to 4 weeks before your target audit start date". Scope agreement is the input to everything downstream |
Month 0 | Window opens. Auditor added, audit created, observation period entered in the platform | Nothing to upload yet | Secureframe warns that "upload-based tests are intended to validate that a control is operating over time, not that evidence was uploaded early" |
Month 1 to 2 | Quarter 1 evidence starts accruing: access reviews, scan cycles, change records | Kick-off, rules of engagement, credentials and environment access | Access provisioning is the most common cause of a slipped start date |
Month 3 to 5 | Quarter 2. The window is established and the environment is stable | Run the penetration test. Report delivered inside the window | The recommended slot. A 38.0-day median close for Highs plus a retest fits comfortably before month 7 |
Month 4 to 7 | Remediation | Fix, track every finding to a ticket, document risk acceptance for anything not fixed | CC4.2 is the criterion being evidenced here, not CC4.1 |
Month 5 to 7 | Retest | Retest and issue the verification artefact | A closed ticket is a claim. A retest is evidence |
Month 6 | Half-way point. Quarterly controls have two cycles behind them | Upload the report, remediation log and retest evidence to the compliance platform | Do it once the retest is done, not before, so the evidence is complete on first submission |
Month 7 to 9 | Quarter 3. Change volume typically peaks | Trigger an additional test after any significant environment change | Drata's guidance is at least annually "or after significant changes to the environment" |
Month 10 to 11 | Quarter 4. Evidence completeness review | Confirm the report date, scope and retest all sit inside the window, and reconcile scope against the final system description | The reconciliation between test scope and system boundary is where late exceptions are found |
Month 12 | Window closes | Nothing new | Anything started here lands outside the period |
Month 12 plus | Fieldwork. Auditor issues the data request list and samples populations | Answer scope and independence questions, produce the tester if asked | Secureframe describes the data request list as the auditor's checklist of "specific evidence, documentation, and data" |
Two rules that apply to the whole window, both from Vanta's audit readiness guidance: keep tests green or document a remediation plan, and "do not alter uploaded documents during the observation window without auditor approval". Replacing a report mid-window without telling the auditor turns a good-faith correction into a question about evidence integrity.
Why month three, and not month eleven
The argument is entirely about the fix window, and the numbers are ours.
Stingrai's State of Penetration Testing 2026 analysed 1,206 verified findings from 55 penetration tests run between October 2024 and August 2026. 92.7% of tests surfaced at least one High or Critical finding. That is the planning assumption: not "we might find something" but "we will find something that has to be tracked, fixed and reverified before fieldwork".
The severities behave differently, and the difference is the whole scheduling problem. Across findings with a tracked resolution time, the median Critical took 10.5 days to close. The median High took 38.0 days. Criticals get emergency attention and clear fast. Highs get triaged into the normal backlog and take roughly five and a half weeks. The dataset also carried a 0.74% false-positive rate, which is small but not zero, and every disputed finding is a conversation you have to document rather than simply close.
Now do the arithmetic, which is the only derived number on this page. A report delivered at the end of month 3 produces a fix cycle that clears its Highs around the middle of month 5, plus a retest. Call it month N plus two. Test in month 3 and the loop closes in month 5. Test in month 11 and the loop closes in month 13, which is outside the window, which means your Type 2 evidence shows findings raised and not verified as remediated inside the period. That is a CC4.2 problem, and it is self-inflicted.
There is a second reason, less arithmetic and more practical. An early test gives you the option of a second one. If the first engagement reveals that your scope was drawn wrong, that an acquired service was never in the system description, or that a new environment went live in month two, you have eight months to fix the scope and test again inside the window. In month eleven you have no options at all.
What auditors actually ask for
Secureframe is explicit that "each auditor sets their own individual requirements regarding the activities needed to satisfy this control", and equally explicit that "all auditors will accept a pen test report as evidence". The report alone, though, rarely closes the request. The full bundle looks like this, with the criterion each piece serves.
Artefact | What it must show | Criterion it evidences |
|---|---|---|
Engagement letter or statement of work | The test was authorised, by whom, and for what scope, with a date preceding the test | CC4.1, that a separate evaluation was selected and performed |
Scope definition | Named applications, environments, domains, IP ranges, user roles and test types | CC4.1, and the reconciliation against your system description |
Methodology | The named approach: OWASP Testing Guide, PTES, or the firm's documented method | CC4.1, that the evaluation was developed rather than improvised |
Dated report | Findings, severities, evidence, remediation guidance, and a test window inside the observation period | CC4.1 |
Remediation tracking | Ticket identifiers, open and close dates, the change that fixed each finding | CC4.2 |
Risk acceptance memos | Named owner, rationale and review date for anything not fixed | CC4.2 |
Retest verification | Written confirmation the fixes hold, dated inside the window | CC4.2 |
Provider qualification | Whatever your own control description promises about the tester | CC4.1, because your control language is the benchmark |
Quarterly scan evidence | One scan per quarter of the window, with a sample of remediated findings inside your SLA | CC7.1 |
Two things to notice. First, five of those nine artefacts are about what happened after the test, which is the part teams under-budget. Second, the last row is a different control on a different clock. Vanta's SOC 2 control language reads "Host-based vulnerability scans are performed at least quarterly on all external-facing systems", and Secureframe explains why the two cadences coexist: quarterly scanning exists "to catch any vulnerabilities introduced by changes that have been made to your environment in the time between your annual penetration tests". A penetration test does not replace the scan cycle.
Secureframe's summary of what the auditor is really assessing is worth memorising, because it reframes the anxiety: "There's no penalties for finding vulnerabilities on a pen test... Remediation in a timely manner is what auditors care about, not necessarily the actual findings (if any)."
The fast path if you are already late in the window
Most people reading this are not planning month three. They are in month nine with fieldwork booked and a red check in their compliance platform. The recoverable sequence, in order:
1. Establish the real deadline, not the assumed one. Ask the auditor two questions in writing: does the test have to fall inside the observation window, and does the retest have to fall inside it too. Secureframe's own documentation contains a strict reading and a looser one for annual controls. Your auditor's answer is the one that counts, and it may buy you weeks.
2. Run an autonomous test immediately to start the clock. The value of testing now is not the report; it is the date. A finding raised inside the window with a tracked remediation and a retest is CC4.2 evidence. The same finding raised after the window closes is nothing. An autonomous test can be scoped and running in days rather than weeks, which is the difference between landing inside the period and missing it. Stingrai's Autonomous Pentest, driven by Snipe, is built for exactly this compression.
3. Triage on the Highs, not the Criticals. Counter-intuitive, but the data says so. Criticals close in a median of 10.5 days because they get emergency attention regardless. Highs are the ones that take 38.0 days and will still be open when fieldwork starts. Pull the Highs forward.
4. Layer hybrid validation before fieldwork. Once the autonomous pass has surfaced and started the fix cycle, a hybrid engagement, where penetration testers work alongside Snipe throughout, gives you the depth on authorization, business logic and chained attack paths that a report has to show to survive an auditor asking what the methodology covered.
5. Document the gap honestly if one remains. If a finding cannot close inside the window, a dated risk acceptance memo with a named owner and a remediation date is a legitimate CC4.2 artefact. An unaddressed open finding with no memo is not. Auditors have seen the first many times; the second is what becomes an exception.
6. Write next year's control description while it hurts. If your control says "annual penetration test", you have committed to a population of one forever. A control that says "penetration testing performed at least annually and after significant changes to the production environment" gives you a defensible reason to test more than once and turns the population from one into several.
Where the compliance platforms fit
Vanta, Drata and Secureframe all treat the penetration test as manual upload evidence, and all three enforce their own clock on top of the auditor's. Vanta's document tests fail when "there are only expired files uploaded", and calculate the next renewal "from the effective date of the uploaded file(s), not the date the document was renewed". Secureframe's daily job archives evidence and fails an upload test once its due date passes, and evidence with reviewer findings noted does not pass at all. Drata's DCF-19 asks for the report plus "evidence of the internal tracking and remediation of findings". Our companion post on penetration testing for Vanta, Drata and Secureframe covers each platform's check in detail.
The thing to hold onto: a green check is a project-management signal. The audit opinion belongs to the auditor, and the auditor is reading dates.
Mistakes that turn timing into an exception
Booking the test in the last quarter of the window. There is no runway for the fix-and-retest loop, and a 38-day median High close will land outside the period.
Uploading the report before the retest is done. Complete evidence on first submission avoids a second round trip during fieldwork, and Secureframe warns against uploading evidence early in the window.
Letting the test scope drift from the system description. The auditor reconciles the two. An application in the description but not in the report is a gap, regardless of when the test happened.
Treating a Type 1 test as covering the Type 2. A Type 1 test can predate the report by up to twelve months. A Type 2 test has to sit in the period. Moving from Type 1 to Type 2 often needs a new test sooner than budgeted.
Writing "annual penetration test" into the control description without thinking. It creates a population of one and a 100% exception rate on any miss.
Changing anything mid-window without telling the auditor. Vanta's rules for the observation window prohibit disabling tests, removing systems from scope, or altering uploaded documents without auditor approval.
Assuming quarterly scans satisfy the testing control. They evidence CC7.1. The test evidences CC4.1. Both are usually expected.
Forgetting the renewal clock. Secureframe's guidance is to start the next cycle "6 months before your current report expires", which means next year's test slot needs to be booked while this year's fieldwork is still running.
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 programme by producing the artefacts an auditor asks for on the dates they need to fall on: a statement of work as its own dated document, a report whose test window is unambiguously inside your observation period, remediation tracking that maps finding to ticket to change, retesting written into the engagement rather than sold as a change order, and a shareable completion letter for customers who ask for proof without needing the technical detail. The compliance opinion itself is your auditor's.
We deliver both one-time annual penetration tests and continuous testing programmes, and the two solve different halves of the Type 2 problem. A one-time engagement placed in month three closes the CC4.1 control cleanly. A continuous programme produces in-window evidence across the whole period, which turns a population of one into a population the auditor can sample, and gives you fresh evidence after every significant environment change without a new procurement cycle.
Snipe, our autonomous web application testing agent, is custom-trained on more than 6,000 HackerOne Hacktivity disclosure reports and on skills distilled from our own testers' methodology. It hunts complex authorization, IDOR and business logic flaws rather than stopping at scanner-class bugs, performs both black box testing and white box source review, generates AutoFix pull requests, and can gate merges on every pull request. Our penetration testers work alongside it throughout the engagement, directing where it looks and extending the attack paths it opens, with both contributing findings across every severity. That is what makes the compressed timeline in the fast path above realistic rather than aspirational.
Published pricing sits 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 larger scope, request a quote.
Frequently Asked Questions
Does SOC 2 Type 2 require a penetration test?
Not as a matter of framework text. The 2017 Trust Services Criteria name penetration testing exactly once, inside a non-binding point of focus under CC4.1 that lists eight evaluation types management "may include", and the criteria set no cadence at all. In practice the answer is closer to yes: Secureframe states that "pen tests are required for SOC 2 Type 2 unless the environment is closed and robust vulnerability scanning is in place", and Vanta and auditors both recommend an annual external test. Where an obligation exists, it usually came from your own control description rather than from the AICPA.
When should I do a penetration test for a SOC 2 Type 2 audit?
In months three to five of a twelve-month observation window. The test has to fall inside the period, and so should the remediation and retest that follow it. Across 1,206 verified findings from 55 penetration tests in Stingrai's dataset, the median High finding took 38.0 days to close, so the fix-and-retest loop runs roughly two months past report delivery. Testing in month three closes the loop by month five and leaves seven months of clean in-window evidence. For a six-month window, move it to month one or two.
Does the penetration test have to be inside the SOC 2 observation window?
For a Type 2, yes. Secureframe states it as "SOC 2 Type 2: Pen test has to occur during the audit period", against "SOC 2 Type 1: Pen test can have taken place anytime in the prior 12 months from the report date". There is a looser reading in Secureframe's own Type 2 review-period guidance for annual controls, which says evidence is needed "at least once in the year prior to the end of the Type 2 window". Ask your auditor which reading they apply and get the answer in writing before you book.
How long is a SOC 2 Type 2 observation period?
Between three and twelve months in practice, and nothing in the criteria fixes it. Secureframe's position is that "the SOC 2 standard is flexible on observation periods, it only requires that the period be long enough to demonstrate operating effectiveness", and that market practice is a shorter three-month first window followed by twelve months thereafter, as an audit-firm methodology rather than a framework rule.
What is the difference between SOC 2 Type 1 and Type 2 for penetration testing?
A type 1 report opines on controls "as of a specified date"; a type 2 opines on controls that "operated effectively throughout the specified period". For testing, that means a Type 1 accepts a test from any time in the prior twelve months, while a Type 2 needs the test inside the period. It also means a Type 2 turns an annual control into a population of one: if the single test is late, out of scope or unretested, the exception rate on that control is 100%, not a fraction.
Which Trust Services Criteria does a penetration test evidence?
CC4.1, which requires the entity to select, develop and perform ongoing or separate evaluations to ascertain whether internal control components are present and functioning. The remediation trail behind the test evidences CC4.2, which requires deficiencies to be evaluated, communicated and tracked to timely remediation. CC7.1 is frequently mis-cited here: its text covers detection and monitoring procedures, and its relevant point of focus is titled "Conducts Vulnerability Scans", so it wants scan evidence rather than a penetration test.
What evidence does an auditor ask for beyond the report?
The engagement letter or statement of work, a scope definition that reconciles against your system description, the named methodology, the dated report, remediation tracking with ticket identifiers and close dates, risk acceptance memos for anything left open, retest verification, evidence supporting whatever your control description promises about the tester, and quarterly vulnerability scan evidence for CC7.1. Five of those are about what happened after the test, which is the part most teams under-budget.
What if I have already missed the window for a penetration test?
Confirm with the auditor whether the test and the retest both have to fall inside the period, because Secureframe's own guidance contains a strict and a looser reading. Then run an autonomous test immediately so findings are raised and tracked with an in-window date, triage the High findings first because they take a median of 38.0 days to close against 10.5 for Criticals, add hybrid validation before fieldwork, and write a dated risk acceptance memo with a named owner for anything that cannot close in time.
Do I need to retest after remediation for SOC 2?
SOC 2 imposes no retest requirement in its criteria text, but CC4.2 requires management to track whether deficiencies are remedied on a timely basis, and a retest is the cleanest way to prove they were. Drata's evidence guidance asks explicitly for "evidence of the internal tracking and remediation of findings", and expects exploitable vulnerabilities resolved within company-defined SLAs. Scope the retest into the original engagement rather than discovering it as a change order.
Can I use last year's penetration test for this year's Type 2 report?
Only if its test window falls inside this year's observation period, which by definition it usually does not. This is the most common timing failure when a company moves from a Type 1 to a Type 2: the Type 1 accepted a test up to twelve months old, and the Type 2 does not. Budget a fresh test for the new period and place it early.
Does a vulnerability scan satisfy the SOC 2 penetration testing control?
It satisfies a different control. Scanning evidences CC7.1, whose point of focus asks for infrastructure and software vulnerability scans "on a periodic basis and after any significant change in the environment". Secureframe explains why both cadences exist: quarterly scanning is there "to catch any vulnerabilities introduced by changes that have been made to your environment in the time between your annual penetration tests". Our comparison of penetration testing and vulnerability assessment covers what each one proves.
Can the test run against a staging environment instead of production?
Secureframe permits it 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. Where staging differs in authentication, exposure or data handling, the result does not transfer. Get the agreement from your auditor in writing before you scope against it.
Related reading
SOC 2 penetration testing in 2026, the scoping, control-wording and cost guide this page complements.
Penetration testing for Vanta, Drata and Secureframe, what each compliance platform's check actually requires.
Pentest evidence auditors accept: SOC 2, ISO 27001, PCI DSS and CMMC, the clause-level analysis behind every criterion quoted here.
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 sequence.
Pentest completion letter versus full report, what to share with customers and what to keep internal.
Cloud pentest scope for a SOC 2 Type 2 on AWS, scoping the cloud half of the boundary.
References
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. Source of the CC4.1, CC4.2, CC7.1 and CC7.2 criterion text, the single point of focus that names penetration testing, and the absence of any cadence language.
AICPA. AT-C section 320, Reporting on an Examination of Controls at a Service Organization Relevant to User Entities' Internal Control Over Financial Reporting. Retrieved 5 September 2026. https://www.aicpa-cima.com. Defines the type 1 report as an opinion as of a specified date and the type 2 report as an opinion on operating effectiveness throughout a specified period.
Secureframe. Pen Testing Requirements. Retrieved 5 September 2026. https://support.secureframe.com/en/articles/15111430-pen-testing-requirements. The Type 1 versus Type 2 timing rule, the not a hard pass or fail statement, and the position that all auditors accept a report as evidence.
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. Observation-period flexibility, the three-month then twelve-month market pattern, the annual external testing line, quarterly scanning rationale, the data request list, and the six-month renewal lead time.
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 rules for weekly, monthly, quarterly and annual controls inside a Type 2 window.
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 practical yes for Type 2, the warning against uploading evidence early, and the UAT environment allowance.
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 at least once every 12 months, and the position that timely remediation matters more than the findings themselves.
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 lead time, the observation-window do and do-not rules, the risk snapshot timing split by report type, and the note that auditors may request a penetration test.
Vanta. Frequently Asked Question: Are Penetration tests and Bug Bounty Programs Required for my Audit? 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 annual external testing recommendation and its vulnerability management bar.
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. The quarterly host-based scanning control language and the one-scan-per-quarter evidence expectation.
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 its quotation of criterion CC4.1.
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, and the expectation of internal tracking, remediation and documented risk acceptance.
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, the 92.7% High or Critical rate, the 10.5 day and 38.0 day median remediation times, and the 0.74% 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.
