SOC 2 Penetration Testing Requirements (2026): Is a Pentest Required?

SOC 2 does not require a penetration test: none of the AICPA's Trust Services Criteria names one as a mandatory control. Penetration testing appears exactly once, as one example of a "separate evaluation" in a CC4.1 point of focus, and points of focus are illustrative rather than required; vulnerability scans sit in the same CC4.1 list and have their own CC7.1 point of focus. Auditors and enterprise customers still expect testing evidence: the Cloud Security Alliance's CAIQ v4.1 questionnaire asks vendors about periodic penetration testing by independent third parties, and in our engagements service auditors routinely ask for an annual third-party test report.

This page is the requirements reference: the criteria text quoted from the AICPA's own copy, which criteria a test can give evidence for, how Type 1 and Type 2 change what the test must prove, what drives frequency, how scope maps to the system description, what an auditor-ready report contains, and what happens when findings are still open at fieldwork. Scoping, month-by-month timing and pricing sit in our companion guide to SOC 2 penetration testing scope, timing and cost.

Quick answer. No. SOC 2's criterion CC4.1 requires the entity to perform "ongoing and/or separate evaluations to ascertain whether the components of internal control are present and functioning", and the 2022 point of focus beneath it says those evaluations "may include ... vulnerability scans, security assessment, penetration testing, and third-party assessments." TSP section 100 adds that use of the criteria "does not require an assessment of whether each point of focus is addressed." A penetration test becomes a SOC 2 requirement only when your own control description, a customer contract or another framework you commit to makes it one. Stingrai's penetration testing produces the evidence auditors use for CC4.1 and CC4.2, and every human-led and hybrid report ships with an attestation letter.

What the Trust Services Criteria actually say about penetration testing

SOC 2 examinations are reported against TSP section 100, the 2017 Trust Services Criteria with Revised Points of Focus (2022). The AICPA publishes the clean copy behind a free login, and also publishes a red-lined version that shows the 2022 changes against the 2017 text. Every quote on this page is the 2022 wording from that AICPA document.

Two structural facts frame everything else. First, the common criteria (CC1 to CC9) are "criteria common to all five of the trust services categories", so the monitoring criteria below apply to every SOC 2 report, whichever categories you add. Second, a criterion is the requirement; a point of focus is an illustration of it.

CC4.1: the only place penetration testing is named

The criterion reads: "The entity selects, develops, and performs ongoing and/or separate evaluations to ascertain whether the components of internal control are present and functioning."

Beneath it, the 2022 revision rewrote the additional point of focus titled "Considers Different Types of Ongoing and Separate Evaluations". The relevant sentence now reads: "Depending on the entity's objectives, such risk and control evaluations may include first- and second-line monitoring and control testing, internal audit assessments, compliance assessments, resilience assessments, vulnerability scans, security assessment, penetration testing, and third-party assessments."

Read the verb. "May include" is permissive, and penetration testing is the seventh item in a list of eight. The 2017 version had named it first ("including penetration testing, independent certification made against established specifications"), so the 2022 rewrite, if anything, made it less prominent. A search of the 2022 text finds no other use of the phrase.

Points of focus are not requirements

TSP section 100 is explicit about the status of every point of focus, including the one that mentions penetration testing:

• Paragraph .07: "Use of the trust services criteria does not require an assessment of whether each point of focus is addressed."

• Paragraph .05: management "may customize a particular point of focus or identify and consider other characteristics based on the specific circumstances of the entity."

• Paragraph .03, citing COSO: points of focus "represent important characteristics of the criteria."

So the criterion binds you (you must evaluate whether controls are present and functioning), and the method is your choice. In our experience, a penetration test is the method SaaS service organizations pick, because it is the one their customers ask about.

CC7.1 names scanning, not penetration testing

CC7.1 requires the entity to use "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 point of focus "Conducts Vulnerability Scans" reads: "The entity conducts infrastructure and software vulnerability scans designed to identify potential vulnerabilities or misconfigurations on a periodic basis and after significant changes are made to the environment."

That point of focus is about scanning. A penetration test can corroborate CC7.1, but it does not replace the scan evidence an auditor is likely to sample there.

The one route by which a pentest becomes mandatory

A paragraph added in 2022, .06, explains that a service organization "may make a commitment about meeting the requirements of a process or control framework", in which case "management and the practitioner are likely to consider the requirements of the process or control framework as additional points of focus." The SOC 2 description criteria treat the same commitments as service commitments, and DC section 200 notes they "may be communicated to user entities in many ways, such as through contracts, service level agreements, and published policies."

In practice that gives you three ways to make a penetration test binding inside your own SOC 2 report:

1. Your control description says you perform one ("The Company engages a qualified third party to perform a penetration test at least annually").

2. A customer contract, SLA or published security page commits you to one.

3. You commit to a framework that mandates one, such as PCI DSS Requirement 11.4.

Once any of those is true, the auditor tests you against that promise.

What is changing for 2027

On 28 October 2026 the AICPA announced exposure drafts of proposed 2027 Trust Services Criteria and Description Criteria. Comments run through 15 January 2027, and the final criteria would be effective for engagements beginning on or after 31 December 2027, with early adoption permitted. The release does not mention penetration testing or vulnerability scanning, and the draft text sits behind a login, so we make no claim about its content here. Until your auditor adopts the final version, the 2017 criteria with the 2022 points of focus quoted on this page govern your report.

Why auditors and customers expect a test anyway

Three forces turn an optional point of focus into a standing expectation.

The criterion still needs evidence. CC4.1 is mandatory even though its methods are not. A service organization has to show the auditor some separate evaluation of its controls, and of the options in the point of focus, an independent penetration test is the one that also answers customer questions. The CC4.1 COSO points of focus add that "Separate evaluations are performed periodically to provide objective feedback" and that evaluators "have sufficient knowledge to understand what is being evaluated", which is why a qualified, independent tester carries weight.

Customers ask for it in writing. The Cloud Security Alliance's CAIQ v4.1, released 27 January 2026, is a standard vendor questionnaire. Its question TVM-07.1 asks: "Are processes, procedures, and technical measures defined, implemented, and evaluated for the periodic performance of penetration testing by independent third parties?" A SOC 2 report that is silent on testing leaves that question to be answered separately.

Auditors look for it. In our engagements, service auditors ask for the most recent penetration test report as a matter of course, and a report with a testing gap draws follow-up questions on CC4.1 and on how vulnerabilities were identified under CC3.2. That is our observation from client audits, not a rule in the standard, and auditors differ, so ask yours early.

Which SOC 2 criteria a penetration test gives evidence for

A penetration test is not a one-criterion artifact. Scoped and documented properly, it supports several criteria; scoped narrowly, it supports one. The map below sets out what each criterion asks, what a test can prove, and the artifact an auditor is likely to sample.

Figure 1: Criteria-to-evidence map for a SOC 2 penetration test. Criteria text from the AICPA 2017 Trust Services Criteria with Revised Points of Focus (2022); artifact column is Stingrai's guidance. Source: AICPA, TSP section 100, red-lined version.

Two cautions. CC7.2 evidence exists only if the engagement exercised detection; a fully allow-listed test with the security team watching the calendar proves nothing about monitoring. And CC8.1 evidence exists only when the test is tied to identifiable changes; an annual test of the whole estate does not show that a specific release was tested.

For a cross-framework view of the same evidence, see pentest evidence auditors accept for SOC 2, ISO 27001, PCI DSS and CMMC.

Type 1 vs Type 2: point in time vs the observation period

DC section 200, the AICPA's description criteria for SOC 2, defines the difference by subject matter. A Type 1 covers the description and "the suitability of the design of the controls". A Type 2 adds "the operating effectiveness of controls" over a period.

That difference decides what the penetration test has to prove.

• Type 1. The auditor needs to see that the evaluation control is designed and in place as of the report date: a defined testing policy, an engaged provider, a scope that matches the system, and usually a recent report. There is no period to cover.

• Type 2. The auditor needs to see that the control operated during the period. A test dated before the period opened evidences the previous period, not this one. The remediation and retest that make up the CC4.2 loop also need dates inside the period, or the auditor sees findings raised but not tracked to resolution.

Figure 2: How penetration test timing relates to a Type 1 report date and a Type 2 observation period (illustrative period, not to scale). Report-type definitions from DC section 200; placement is Stingrai's guidance. Source: AICPA, DC section 200.

Why timing inside the period matters

The Type 2 description also has to disclose change. DC 9 requires, in a Type 2, "the relevant details of significant changes to the service organization's system and controls during that period", and its examples include "Significant changes to system processes, IT architecture and applications." A new product line, a re-platforming or a cloud migration in month seven is a significant change the report will describe. If your control description promises testing after significant changes, the auditor will look for a test after that one.

Test early enough in the period that fixes and the retest land inside it, and leave room before fieldwork. Our SOC 2 scope, timing and cost guide walks through month-by-month placement for three, six and twelve month windows.

How often SOC 2 expects penetration testing

The criteria set no frequency. The words "annual", "quarterly" and "at least once" do not appear anywhere in TSP section 100. What they do set is the logic that frequency has to follow:

• Risk. The CC4.1 point of focus "Adjusts Scope and Frequency" reads: "Management varies the scope and frequency of separate evaluations depending on risk."

• Rate of change. "Considers Rate of Change" asks management to consider "the rate of change in business and business processes when selecting and developing ongoing and separate evaluations."

• Changing threats. The 2022 CC3.4 point of focus "Assesses Changes in Threats and Vulnerabilities" asks the risk process to assess changes in "internal and external threats to and vulnerabilities of the components of the entity's systems."

• Significant changes. CC7.1 ties scanning to "a periodic basis and after significant changes are made to the environment", and DC 9 makes those changes visible in the report.

• Commitments. Anything you promised in a contract, SLA or published policy is a service commitment the report evaluates, and anything your control description says becomes the standard the auditor tests.

The answer we see auditors accept most readily is an annual third-party test, plus a targeted test after significant changes, written into the control description in those words. Teams that ship weekly often move the flagship application to continuous testing so "after significant changes" is met without manual scheduling; our explainer on how often to run penetration testing covers the trade-offs. Whatever you choose, write only the cadence you can evidence, because the sentence becomes the test.

Scope that maps to the system description

The SOC 2 report opines on a described system, and the test should cover that system. DC 3 requires the description to set out "the components of the system used to provide the services": infrastructure, software, people, procedures and data. DC section 200 defines the boundaries of the system as "the specific aspects of a service organization's infrastructure, software, people, procedures, and data necessary to provide its services", and its guidance notes that "Not all activities performed at the service organization are part of the system being described."

That gives a practical scoping rule: start from the description, not from what is convenient to test.

1. List every customer-facing application and associated APIs in the description. Each one is in scope unless the description excludes it.

2. Test authenticated, across roles and tenants. Multi-tenant separation and authorization are where SOC 2 risk concentrates, and an unauthenticated test never reaches them. Our web application penetration testing covers every role.

3. Include the infrastructure layer the description names. If production runs in AWS, Azure or Google Cloud, the identity and configuration paths in those accounts are part of the system. See cloud pentest scope for SOC 2 Type II on AWS and our cloud penetration testing service.

4. Account for third-party access. DC section 200 notes that vendors and partners "may provide components of the system"; integrations, support tooling and administrative access paths belong in the test if they belong in the description.

5. Name the environment. Testing a configuration-identical staging environment can be defensible, but only if the scope document says so and the description does not promise production.

6. Record exclusions. Anything left out should be listed with a reason, so the auditor can reconcile the scope against the description.

What an auditor-ready penetration test report contains

To the service auditor, your penetration test report is information produced by the entity. AT-C section 205, the attestation standard SOC 2 examinations follow, requires the auditor to "evaluate whether the information is sufficiently reliable", including "Obtaining evidence about the accuracy and completeness of the information" and "Evaluating whether the information is sufficiently precise and detailed." A report earns that reliability with seven elements:

The attestation letter is what you send to the customer whose questionnaire asks TVM-07.1, and it keeps full findings out of procurement inboxes. Our guide to the pentest completion letter vs the full report explains which document goes to whom, and how to evaluate a penetration test report covers report quality in more depth.

Vulnerability scanning vs penetration testing for SOC 2

The two do different jobs and should not be substituted for each other. The 2022 CC4.1 point of focus lists both vulnerability scans and penetration testing among the separate evaluations an entity may use, and CC7.1 adds a point of focus that names scanning alone. NIST defines vulnerability scanning as "A technique used to identify hosts/host attributes and associated vulnerabilities", and penetration testing as "A test methodology in which assessors, typically working under specific constraints, attempt to circumvent or defeat the security features of a system."

A scan programme on its own can be cited under CC4.1, but it does not show whether broken authorization or business logic flaws can be exploited, and customer questionnaires such as TVM-07.1 ask specifically about penetration testing by independent third parties. A penetration test without a scan programme leaves the CC7.1 point of focus unanswered. A programme built around the points of focus needs both; our comparison of penetration testing vs vulnerability assessment across compliance frameworks goes further.

What happens if findings are open at audit time

Findings still open at fieldwork are not automatically a problem. The distinction that matters is between a deficiency, which is yours to manage, and a deviation, which is the auditor's to report.

A finding feeds a deficiency process. CC4.2 requires the entity to evaluate and communicate "internal control deficiencies in a timely manner to those parties responsible for taking corrective action", and its point of focus says "Management tracks whether deficiencies are remedied on a timely basis." A High finding with a ticket, an owner, a target date and a retest scheduled is that control operating.

A deviation is a control that did not operate as described. AT-C section 205 paragraph .26 says that when the auditor "identified deviations in those controls, the practitioner should make specific inquiries and perform other procedures as necessary to understand these matters and their potential consequences." In the SOC 2 reports clients share with us, these appear in the tests of controls as exceptions. Typical penetration-testing deviations come from your own wording: no test in the period when the description promised an annual one, no test after a significant change when the description promised that, or Critical findings left open past a remediation deadline the description set.

Deviations do not automatically qualify the opinion. AT-C 205 counts "the number of observed deviations in the operation of a control" among the factors in judging materiality, and paragraph .72 reserves a qualified opinion for matters that are "material, but not pervasive." In the reports we see, exceptions regularly sit alongside an unmodified opinion; the auditor's description of the test and its result is what customers read.

An exploited finding is a different matter. DC 4 requires disclosure of system incidents that resulted from controls "not suitably designed or operating effectively" or that caused "a significant failure" in meeting service commitments. An open vulnerability is not an incident; evidence that someone used it may be.

Management can respond in the report. In the reports clients share with us, management's response to each exception sits in a section of other information, and AT-C 205 paragraph .58 has the auditor read other information "to identify material inconsistencies." A dated remediation plan with a named owner is a better response than a promise.

What to do before fieldwork:

1. Close what you can, and retest it inside the period.

2. For each finding still open, record the owner, the target date, any compensating control and the rationale.

3. Get formal risk acceptance from the right level of management for anything you will not fix.

4. Check your control description: if it sets remediation deadlines, make sure the evidence meets them, or change the wording for the next period.

How SOC 2 sits next to ISO 27001, PCI DSS 11.4 and HIPAA

PCI DSS mandates a penetration test in Requirement 11.4; SOC 2 and the HIPAA Security Rule in force do not name one, and ISO 27001 is covered in our separate guide. One well-scoped test can still serve several of them.

Two notes. PCI DSS also requires the test to be performed by "a qualified internal resource or qualified external third-party" with "Organizational independence of the tester", which is a higher bar than SOC 2 sets, so a test built to PCI's bar can also serve SOC 2 when its scope covers the SOC 2 system. And the HIPAA proposal remains a proposal: as of 30 October 2026, the Federal Register lists only the proposed rule under RIN 0945-AA22. Framework-specific detail is in our guides to PCI DSS penetration testing and HIPAA penetration testing requirements.

SOC 2 penetration testing requirements checklist

A first-year plan for a SOC 2 penetration testing control

1. Write the control sentence first. Decide the cadence you can hold ("at least annually and after significant changes to the production environment") and the adjectives you can evidence ("independent", "qualified").

2. Reconcile scope to the system description. List applications and associated APIs, cloud accounts, integrations and administrative paths; record exclusions.

3. Confirm the scan programme. CC7.1 evidence comes from scans; make sure they run on schedule before the period opens.

4. Book the test early in the period. Leave time for remediation, the retest and evidence assembly before fieldwork.

5. Run the CC4.2 loop. Ticket every finding, assign owners, retest fixes, and document risk acceptance for anything left open.

6. Reconcile changes to tests. Compare the change log against your testing dates and test after any significant change you committed to cover.

7. Assemble the evidence pack. Engagement letter, scope, methodology, report, tickets, retest results, risk acceptances, tester qualifications and the attestation letter for customers.

What a SOC 2 penetration test costs

Cost depends on scope rather than on the framework; ranges by test type are in our SOC 2 penetration testing scope, timing and cost guide. Stingrai's fixed prices for one web application and associated APIs are US$3,000 for the Autonomous Pentest and US$6,800 for the Hybrid Pentest with penetration testers, per assessment; current terms are on the pricing page, and anything larger is quoted.

Questions to ask a SOC 2 penetration testing vendor

• Will the scope document reconcile to our system description, application by application?

• Who are the named testers, and what certifications do they hold?

• Is retesting of remediated findings included, and how fast is it turned around?

• Does the report state methodology, scope, dates, severity and evidence per finding?

• Do we get an attestation letter we can share with customers?

• Can findings flow into our ticketing system so the CC4.2 trail builds itself?

• Can you test after a significant change at short notice, inside our observation period?

Where Stingrai fits

Stingrai is a global CREST-accredited penetration testing services company founded in Toronto, Canada in 2021, trusted by companies from startups to enterprises to meet audit requirements for SOC 2, ISO 27001, CMMC, PCI DSS and HIPAA. OSCE³, OSWE, OSEP, CREST CRT certified penetration testers, who are also world-class security researchers and bug bounty hunters. Choose from fully human-led or hybrid (AI agents plus human penetration testers) engagements across web, API, mobile, AI and LLM, cloud, network, Active Directory and social engineering penetration tests and red team engagements.

For a SOC 2 programme, that translates into the evidence this page describes. Each human-led engagement is staffed by two named penetration testers from a team holding OSCE³, OSWE, OSEP, CREST CRT and CISSP certifications, reviewed by the team lead and an engagement partner, so the "knowledgeable personnel" and "objective" questions have names behind them. Every finding is posted to the PTaaS portal as it is confirmed, with a working proof of concept and prioritized remediation guidance, and pushes into Jira or Slack, so the CC4.2 trail starts during the test rather than after it. Retesting of remediated findings is included, and every human-led and hybrid report ships with an attestation letter for customer due diligence. Stingrai runs both one-time annual tests and continuous programmes through PTaaS, so a promise of testing "after significant changes" can be met on the flagship application without a second vendor. For a single web application, the Hybrid Pentest puts Snipe, our autonomous agent for web applications and associated APIs, and penetration testers on the application together throughout the engagement.

Frequently Asked Questions

Does SOC 2 require penetration testing?

No. None of the AICPA Trust Services Criteria names penetration testing as a mandatory control. It appears once, in a CC4.1 point of focus that says separate evaluations "may include" penetration testing among eight options, and TSP section 100 states that use of the criteria "does not require an assessment of whether each point of focus is addressed." CC4.1 itself is mandatory, so you must evidence some separate evaluation, and in Stingrai's experience auditors and enterprise customers expect that to include an annual third-party penetration test. It becomes binding when your control description, a customer contract or a framework you commit to says so.

Is a pen test required for a SOC 2 Type 2 report?

Not by the criteria. A Type 2 reports on operating effectiveness over a period, so if your control description includes a penetration test, the test, the remediation and the retest need dates inside the observation period. A test dated before the period opened evidences the previous period and will not support this one.

How often do you need a penetration test for SOC 2?

SOC 2 sets no frequency. The CC4.1 points of focus say management "varies the scope and frequency of separate evaluations depending on risk" and considers the rate of change in the business. The cadence we see auditors accept most readily is at least annually and after significant changes, written into the control description, which then becomes the standard the auditor tests against.

Which SOC 2 criteria does a penetration test satisfy?

CC4.1 is the primary home, because its point of focus lists penetration testing as a separate evaluation. The remediation and retest trail evidences CC4.2. With the right scope and documentation, a test also supports CC3.2 (identifying vulnerabilities of system components), CC7.1 (as corroboration of scanning), CC7.2 (if detection was a test objective) and CC8.1 (if the test is tied to specific changes).

Can a vulnerability scan replace a penetration test for SOC 2?

Not in practice, and the reverse is also true. The 2022 CC4.1 point of focus lists vulnerability scans and penetration testing side by side as possible separate evaluations, and CC7.1's point of focus names vulnerability scans run "on a periodic basis and after significant changes are made to the environment". A scan identifies known vulnerabilities on hosts; a penetration test attempts to circumvent security controls, which is what finds broken authorization and business logic flaws. A programme built around the points of focus needs both.

What should a SOC 2 penetration test report include?

Methodology, scope and dates, tester names and qualifications, findings with severity and evidence, remediation guidance, retest results per finding, and an attestation letter for customers. AT-C section 205 requires the auditor to evaluate whether information produced by the entity is accurate, complete and "sufficiently precise and detailed", and those elements are what make a report meet that test.

What happens if pentest findings are still open during the SOC 2 audit?

Open findings are not automatically exceptions. CC4.2 requires deficiencies to be communicated and tracked to remediation, so a finding with an owner, a target date and a retest plan shows the control operating. An exception (AT-C 205 calls it a deviation) arises when a control did not operate as described, for example a missed remediation deadline that your own control description set. AT-C 205 reserves a qualified opinion for matters that are material but not pervasive.

Does the penetration test have to be done by a third party for SOC 2?

No. SOC 2 sets no independence or certification requirement for the tester, though the CC4.1 points of focus expect evaluators with "sufficient knowledge to understand what is being evaluated" and separate evaluations that "provide objective feedback." If your control description says "independent" or "qualified third party", the auditor will verify that, and customer questionnaires such as the CSA CAIQ v4.1 ask about testing "by independent third parties."

Will the 2027 Trust Services Criteria change the penetration testing requirement?

Unknown yet. The AICPA announced exposure drafts of proposed 2027 criteria on 28 October 2026, with comments through 15 January 2027 and a proposed effective date for engagements beginning on or after 31 December 2027. The AICPA's release does not mention penetration testing, so plan against the current 2017 criteria with the 2022 points of focus.

Can one penetration test cover SOC 2, PCI DSS and HIPAA?

Usually, if the scope covers every system each framework cares about. PCI DSS Requirement 11.4 is the strictest: internal and external tests "At least once every 12 months" and after significant changes, by a qualified and organizationally independent tester, with corrections retested. A test built to that standard and scoped to your SOC 2 system description generally serves SOC 2 and supports the HIPAA Security Rule's periodic evaluation as well.

Related reading

• SOC 2 penetration testing: scope, timing and cost (2026)

• Pentest evidence auditors accept for SOC 2, ISO 27001, PCI DSS and CMMC

• Cloud pentest scope for SOC 2 Type II on AWS

• Best penetration testing companies for SOC 2 (2026)

• How to prepare for SOC 2 audits

References

1. AICPA. 2017 Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy (With Revised Points of Focus, 2022), TSP section 100. 2022. https://www.aicpa-cima.com/resources/download/2017-trust-services-criteria-with-revised-points-of-focus-2022. The criteria and points of focus for SOC 2; clean copy requires a free login.

2. AICPA. Trust Services Criteria, Red-Lined Version (2022 revisions to the 2017 TSC). October 2022. https://assets.ctfassets.net/rb9cdnjh59cm/2sK6Ih6dzy6t7aU6RQvoeD/d97a2a14609e74a1af1ce9ab0b142b69/92317096_trust_services_criteria_red-lined_version.pdf. The public AICPA copy used for every criteria quote on this page.

3. AICPA. 2018 Description Criteria for a Description of a Service Organization's System in a SOC 2 Report, DC section 200 (With Revised Implementation Guidance, 2022). https://www.aicpa-cima.com/resources/download/get-description-criteria-for-your-organizations-soc-2-r-report. Defines Type 1 and Type 2 subject matter, system components, boundaries, incidents and significant changes. Criteria and guidance quoted from the AICPA's 2018 edition (https://web.archive.org/web/20180817212931id_/https://www.aicpa.org/content/dam/aicpa/interestareas/frc/assuranceadvisoryservices/downloadabledocuments/dc-200.pdf); the 2022 revision changed the implementation guidance, not the criteria.

4. AICPA. AT-C section 205, Assertion-Based Examination Engagements (SSAE No. 21). Effective for reports dated on or after 15 June 2022. https://web.archive.org/web/2022id_/https://us.aicpa.org/content/dam/aicpa/research/standards/auditattest/downloadabledocuments/at-c-00205.pdf. Attestation standard covering deviations, information produced by the entity, other information and modified opinions.

5. AICPA. AICPA proposes update of SOC 2 Trust Services Criteria. 28 October 2026. https://www.aicpa-cima.com/news/article/aicpa-proposes-update-of-soc-2-r-trust-services-criteria-to-enhance-the-relevance-usability-and-value-of-cpas-reports. Exposure draft timing and proposed effective date.

6. EY. To the Point: AICPA revises guidance on applying its Trust Services Criteria and SOC 2 Description Criteria. 2 November 2022. https://www.ey.com/content/dam/ey-unified-site/ey-com/en-us/technical/accountinglink/documents/ey-ttp17549-221us-11-02-2022.pdf. Confirms the 2022 revision changed points of focus and guidance, not the criteria.

7. Cloud Security Alliance. Cloud Controls Matrix and CAIQ v4.1. Released 27 January 2026. https://cloudsecurityalliance.org/artifacts/cloud-controls-matrix-v4-1. Vendor questionnaire; question TVM-07.1 covers periodic third-party penetration testing.

8. NIST. CSRC Glossary: penetration testing and vulnerability scanning. https://csrc.nist.gov/glossary/term/penetration_testing and https://csrc.nist.gov/glossary/term/vulnerability_scanning. Definitions drawn from NIST SP 800-53 Rev. 5 and SP 800-115.

9. PCI Security Standards Council. Payment Card Industry Data Security Standard: Requirements and Testing Procedures, Version 4.0.1. June 2024. https://www.pcisecuritystandards.org/document_library/. Requirements 11.4.2 to 11.4.4 on penetration testing frequency, tester qualification and retesting. PCI DSS v4.0 was retired on 31 December 2024 in favour of v4.0.1.

10. US Government Publishing Office (eCFR). 45 CFR 164.308, Administrative safeguards. Current as of 28 October 2026. https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C/section-164.308. HIPAA evaluation standard at (a)(8).

11. US Department of Health and Human Services. HIPAA Security Rule To Strengthen the Cybersecurity of Electronic Protected Health Information (proposed rule), 90 FR 898. 6 January 2025. https://www.federalregister.gov/documents/2025/01/06/2024-30983/hipaa-security-rule-to-strengthen-the-cybersecurity-of-electronic-protected-health-information. Proposed 12-month penetration testing requirement.

Talk to Stingrai

If your control description promises a penetration test, Stingrai can scope it to your system description and deliver the report, retest and attestation letter your auditor and customers will ask for. Get a Quote or book a free discovery call.