Which compliance frameworks require a penetration test and how often
If you are scoping one penetration test to satisfy several audits, the short answer is that the frameworks differ on whether a test is mandatory, how often it must happen and who may run it. PCI DSS requires internal and external penetration tests at least every 12 months and after any significant infrastructure or application change (requirements 11.4.2 and 11.4.3). DORA requires threat-led penetration testing at least every three years, but only for financial entities that their competent authority identifies. CIS Safeguard 18.2 and CMMC Level 3 requirement CA.L3-3.12.1e both call for at least annual testing, with CMMC adding testing after significant security changes. NIST SP 800-53 control CA-8 requires testing at an organization-defined frequency, so the interval is yours to set and document. SOC 2 mentions penetration testing only as an example in a point of focus under CC4.1, so it does not oblige you to test. The HIPAA Security Rule does not use the term today, while the January 2025 proposed rule would require testing at least every 12 months.
The applicable regimes decide the scope, and the strictest applicable requirement usually sets it. For a card-processing organization that is also a HIPAA covered entity, a single test that covers the cardholder data environment and the systems holding electronic protected health information, run at least yearly and after significant change, would meet the most frequent published interval in that list. Confirm with each assessor whether they accept one shared report, and whether they require a qualified tester, a defined methodology or a particular scope boundary. Also confirm the scope of your DORA status with your competent authority before counting on a three-year cycle. Note that none of the frameworks listed issues a penetration testing certificate. The test produces a report that your assessors or auditors review, so budget for the report and remediation evidence, not a badge.
How each framework states its penetration testing requirement
This table sets out, for each framework on the shortlist, whether a penetration test is required, how often, who may run it and what proof the test produces. Read across a row to see how one framework's testing rule translates into evidence, and check the last column before assuming one test will satisfy every audit.
| Framework | Test required and frequency | Who may perform it | What proof results |
|---|---|---|---|
| PCI DSS v4.0.1 (11.4.2 and 11.4.3) | Internal and external penetration tests at least every 12 months and after significant infrastructure or application change | Testers the assessed entity arranges, reviewed as part of the QSA assessment | QSA-reviewed Report on Compliance or SAQ, with an Attestation of Compliance |
| SOC 2 (CC4.1 point of focus only) | Penetration testing appears only as an example evaluation type under CC4.1, not as a required criterion | Determined by management and the service auditor for the system in scope | CPA examination report (Type 1 or Type 2), with no pass certificate |
| HIPAA today (45 CFR 164.308(a)(8)) | No penetration test named; periodic technical and nontechnical evaluation is required | Entity-defined evaluator, typically a qualified internal or external party | Documented evaluation; no certification, and HHS does not recognize private certificates |
| HIPAA under the January 2025 proposed rule | Penetration testing at least every 12 months, or more often if the risk analysis calls for it | A qualified person, as the proposed text defines it | Not yet in force; as of October 2026 no final rule has been published |
| DORA (threat-led penetration testing) | TLPT at least every 3 years for entities the competent authority identifies, with frequency adjustable by risk profile | Testers meeting the Regulation's requirements, as the competent authority determines | Authority-issued attestation under Article 26(7) that the TLPT met requirements |
| CIS Safeguard 18.2 | Periodic external penetration tests, no less than annually, including reconnaissance of the environment | Not specified beyond the safeguard's own requirements; confirm tester qualifications with your program | Assessed against the CIS Controls specification; no certificate issued by CIS |
| CMMC Level 3 (CA.L3-3.12.1e) | Penetration testing at least annually or after significant security changes, using automated tools and expert ad hoc tests | Internal or contracted testers, assessed by DCMA DIBCAC at Level 3 | DCMA DIBCAC assessment result for Level 3 certification |
| NIST SP 800-53 CA-8 | Penetration testing at an organization-defined frequency on defined systems | Set by the organization in its control implementation | Assessment evidence for the control; no external certification scheme |
Who may run the test under each framework
Several frameworks accept a test run by people inside the organization, provided they have the skills the standard expects. The January 2025 HIPAA proposed rule would require penetration testing by a 'qualified person' at least once every 12 months, or more often if the risk analysis calls for it. PCI DSS sets yearly internal and external tests, and CIS Safeguard 18.2 asks for periodic external tests at least annually, so an internal team may cover some of these obligations while leaving others open. In practice:
- HIPAA proposed rule: the text asks only for a qualified person, so define qualification in your own policy and keep records that show it.
- PCI DSS 11.4.2 and 11.4.3: internal and external tests must run at least every 12 months and after significant changes, but the standard text governs who may perform and report them.
- Independence: the facts available to this page do not settle whether a tester may also operate the systems under test, so ask your assessor how they will treat that.
- SOC 2 evaluation: penetration testing appears in a point of focus beside internal audit assessments, so internal work can be one evaluation type, subject to your auditor's view.
Confirm the tester qualification wording in each standard text and in your assessor's checklist before you assign the work to staff.
Buyers who need an outside view of their controls often engage an independent firm for the penetration test. An outside firm can cover several obligations in one engagement, but each assessor still decides what evidence it will accept. Certification and attestation roles are separate from the test itself, so the firm's report and the assessor's conclusion are different documents. Points to check:
- Combined scope: an external firm can cover the external test under PCI DSS 11.4.3 and the external reconnaissance in CIS Safeguard 18.2, if the scope statement names both.
- Assessor acceptance: a QSA evaluates the evidence in a Report on Compliance, so confirm whether that assessor will rely on a test report from a firm it did not engage.
- CMMC Level 3: DCMA DIBCAC performs the Level 3 assessment, so the penetration test is evidence reviewed by the government assessor, not a certification issued by the tester.
- SOC 2 reliance: the CPA examines how testing fits into the control design, so ask whether the auditor will read the firm's report directly or only the summary you provide.
Ask the firm for written tester credentials and a scope that maps to each standard, then confirm that map with each assessor before testing begins.
DORA is the one framework on this page where the tester itself is tied to the Regulation's own requirements. Financial entities identified by their competent authority must carry out threat-led penetration testing (TLPT) at least every three years, and the authority may ask for more or less frequent testing based on the entity's risk profile. Article 26(7) provides for an authority-issued attestation that a TLPT met the requirements, and it is the only authority-issued attestation the Regulation provides for. Key points:
- Identification first: TLPT applies to entities the competent authority identifies, so confirm your status before you budget a threat-led exercise.
- Tester requirements: the Regulation sets conditions that testers must meet; read Article 26 in the EUR-Lex text and confirm how your authority interprets them.
- Frequency adjustment: the three-year baseline can change with the risk profile your authority assigns, which changes your testing calendar.
- Attestation file: the Article 26(7) attestation confirms that the test met the requirements, so plan the evidence file to support it from the start.
Confirm the tester conditions, scope and attestation process with your competent authority before you engage any firm.
Some frameworks require or describe penetration testing without setting a tester qualification in the text available to this page. NIST SP 800-53 control CA-8 requires testing at an organization-defined frequency on defined systems, and the catalog describes it as a specialized assessment that goes beyond automated vulnerability scanning. The SOC 2 criteria mention penetration testing only in a point of focus, and the current HIPAA Security Rule relies on a periodic evaluation standard that does not use the term. Points to note:
- CA-8: you set the frequency and system scope, and the control does not by itself say who must run the test, so document your selection criteria.
- CIS Safeguard 18.2: the annual minimum applies to external tests with reconnaissance to find exploitable information, and the tester profile is left to your program.
- SOC 2 CC4.1: penetration testing is listed beside independent certification and internal audit as types of evaluation, and points of focus are not separate requirements.
- HIPAA today: the evaluation standard in 45 CFR 164.308(a)(8)(8)) calls for periodic technical and nontechnical evaluation, without naming a tester.
Ask each auditor to state in writing which tester profile it accepts for each framework before you scope one test to serve several audits.
What changes the scope of one penetration test
A single penetration test can satisfy several audits only when its scope covers every system and trigger those audits name. The cards below cover the factors that most often widen scope, and the checks to run before you agree a statement of work.
Strictest test frequency
Frameworks set different floors: PCI DSS requires internal and external tests at least every 12 months, CMMC Level 3 requires annual testing or after significant security changes, and the HIPAA proposed rule would require tests at least every 12 months. Build one calendar around the shortest interval that applies to you, and confirm with each assessor which interval they will accept. Where a risk analysis calls for more frequent testing, that interval governs.
Cardholder data environment inclusion
PCI DSS internal (11.4.2) and external (11.4.3) tests apply to the cardholder data environment and anything connected to it. If your payment systems share networks, directory services or administration paths with other systems, a test scoped to the payment application alone may miss the pivot routes an assessor expects you to cover. Ask your QSA to confirm the segmentation boundary before scoping.
CMMC and ePHI system boundaries
CMMC Level 3 testing applies to systems within the defined assessment boundary, and the HIPAA proposed rule would apply to relevant electronic information systems holding ePHI. Both are often wider than a single application. List every system in each boundary, including identity, backup and logging infrastructure, so one test can produce evidence for both. Confirm with the assessor whether the boundary is accepted as drawn.
Significant change triggers
PCI DSS requires retesting after any significant infrastructure or application upgrade or change, and CMMC Level 3 requires testing when significant security changes are made. A major platform upgrade or a new internet-facing service can therefore trigger an extra test between scheduled cycles. Agree a written definition of significant change with your team and assessors, and record each change decision so you can show why a test was or was not triggered.
Threat-led testing eligibility
DORA threat-led penetration testing applies only to financial entities that the competent authority identifies, and it runs at least every three years, with the authority able to request a different frequency based on risk profile. If you are not identified, DORA's TLPT requirement does not apply, but your other frameworks still do. If you are identified, a TLPT is a distinct exercise that may not substitute for the annual tests PCI DSS or CMMC expect, so confirm this with your authority and assessors.
SOC 2 and PCI evidence reuse
A QSA cannot rely on a SOC 2 or SOC 3 report for PCI DSS, but may reuse evidence from those audits after independently reviewing it, which can reduce duplicated work. A SOC 2 test result is therefore useful input, but only if its scope, date and findings match the PCI boundary. Keep the test report, scope statement and remediation evidence together so the QSA can review them directly.
How to confirm the requirement in your own environment
This sequence turns the framework-level penetration testing requirements into a written test scope that one assessment can support. Each step ends with a record your assessor, regulator or auditor can review before any testing starts.
List every audit and regulator in scope
Start with a register of every assessment, attestation and supervisory relationship that touches the environment. Include the payment brands or acquirer for card data, the SOC 2 auditor if one is engaged, the HHS-regulated business units if electronic protected health information is in scope, the competent authority if you are a financial entity under DORA, and any DoD contract that requires CMMC. Record who owns each relationship and which assessor or regulator will accept the evidence. The output is one list with a named contact for each line.
Extract the penetration test clause from each text
For each framework on the register, pull the exact penetration testing clause from the current official text, not from a secondary summary. Cover the PCI DSS requirements for internal and external testing, the SOC 2 point of focus, the HIPAA evaluation standard and any proposed rule your team is tracking, the DORA threat-led testing article, the CIS Safeguard, the CMMC practice and NIST SP 800-53 CA-8. Note whether each clause is a requirement, a point of focus or an informative item. The output is a clause sheet that quotes or cites each source and marks its legal status.
Record frequency triggers and tester rules
For each clause, record the frequency, the trigger events and the qualification rules for the tester. Some texts set a fixed interval, others require testing after significant change, and some leave the frequency to the organization or the risk analysis. Note who may perform the test, such as a qualified person, a subject matter expert or a qualified assessor, and whether independence or organizational separation is stated. Flag any gap where the text is silent so you can ask the assessor directly. The output is a table of frequency, trigger and tester rule per framework.
Map systems to each assessment boundary
Identify which systems, networks, applications and data flows fall inside each boundary. The cardholder data environment, the electronic protected health information systems, the critical ICT services under DORA and the controlled unclassified information systems each define scope differently. Include connected systems that could affect security even when they hold no regulated data. Mark the systems that sit in more than one boundary, because a single test may need to cover them. The output is a boundary matrix that shows each system and the assessments it belongs to.
Confirm whether one report is acceptable
Ask each assessor or regulator, in writing, whether one penetration test report can support its requirement. Ask what scope, method and date they need to see, whether they accept evidence prepared for another audit, and whether they require a separate statement for each framework. Note that PCI SSC guidance lets a QSA reuse evidence from SOC 2 or SOC 3 work only after independent review, so the same logic applies to other reports. The output is a written reply from each party, filed with the scope record.
Agree the evidence format before testing starts
Before any testing begins, agree the format of the deliverable with the tester and each assessor. Confirm the report structure, the level of detail on exploitable findings, how remediation and retest results will be recorded, and how the report will be shared with each audience. Set the test date rules so that changes after the test trigger a new test where the clause requires one. The output is a signed scope document and an evidence checklist that maps each report section to the clause it supports.
Where one test does not satisfy every audit
A penetration test is evidence, not a certificate, and no single test settles every audit. Each assessor decides what evidence it accepts, so a report that satisfies one PCI DSS QSA may draw questions from a SOC 2 auditor or a HIPAA reviewer. The SOC 2 reference to penetration testing sits in a point of focus under CC4.1, which lists it as one possible type of evaluation alongside independent certification and internal audit. It is not a requirement, so a SOC 2 auditor will want to see how the test feeds your monitoring of controls, not just that it happened. Confirm in writing, before fieldwork, which scope, tester qualifications and report format each assessor will accept.
Several obligations in this comparison depend on conditions that may not apply to you. The DORA threat-led penetration test is required only for financial entities that their competent authority has identified, and the authority sets the frequency based on the entity's risk profile, so a generic three-year cycle should not be assumed without that determination. The HIPAA proposed rule of January 2025 would require testing every 12 months, but it is not final. The latest Unified Agenda lists it under Long-Term Actions with final action projected for July 2027, so the current Security Rule text, which does not name penetration testing, still governs. Plan around the current rule and track the proposal separately.
The practical step is to write a single scope document that maps each test element to each audit requirement: PCI DSS 11.4.2 and 11.4.3 in-scope systems, the Safeguard 18.2 external reconnaissance expectations, CA-8 defined components and the CMMC CA.L3-3.12.1e tester approach. Ask each assessor to confirm acceptance of the shared test, its date, its tester and any re-test in writing. Where an assessor will not accept a shared report, budget for a separate engagement, and note that the cost of that second test should be quoted against the written scope rather than assumed.
Penetration testing questions buyers ask before hiring help
Can one penetration test satisfy both PCI DSS and SOC 2?
Often part of the work can be shared, but no single test satisfies both on its own. PCI DSS requires internal penetration testing (11.4.2) and external penetration testing (11.4.3) at least once every 12 months and after any significant infrastructure or application upgrade or change, and the results must be documented on PCI SSC templates. SOC 2 does not name penetration testing in any of its 61 criteria of the 2017 Trust Services Criteria. It appears only in a CC4.1 point of focus, so an auditor may accept it as one type of evaluation. Ask your QSA and your CPA firm in advance whether they will accept the same test report, the same tester and the same scope. A QSA may reuse evidence from a SOC 2 audit only after independently reviewing it, so a SOC 2 report cannot replace the PCI work.
How often does DORA threat-led penetration testing apply to us?
DORA threat-led penetration testing (TLPT) applies only to financial entities that the competent authority identifies. Those entities must carry out TLPT at least every 3 years, but the authority can ask for more or less frequent testing based on the entity's risk profile. If you have not been told you are in scope, confirm with your competent authority rather than assume. Companies outside that identified group still face general ICT testing expectations under the regulation, which you should map to your own risk assessment. Article 26(7) is the only attestation DORA provides for, and it confirms that a TLPT met the regulation's requirements.
Can our internal staff run the penetration test ourselves?
It depends on which framework you are answering to and who the auditor will accept. PCI DSS requires penetration testing by a qualified internal resource or qualified external third party with organizational independence, so your own team may perform internal testing if it meets that standard, and an external provider is typically needed for the external test. HIPAA's proposed rule would require testing by a qualified person, and CMMC Level 3 expects automated scanning plus ad hoc tests by subject matter experts. Confirm the tester qualification and independence requirements with your assessor before scheduling. Internal teams often run the recurring tests well, but an independent tester usually strengthens the evidence for an audit.
What drives the cost and effort of a penetration test?
No supplied figure sets a price, so the main cost drivers are the scope and the work around it. Scope includes the number of systems, applications, APIs, networks and cloud accounts, plus whether testing is external, internal, or both. Frequency matters because PCI DSS testing recurs yearly and after significant changes, and DORA TLPT recurs at least every three years. Reporting format matters because a report built on PCI SSC templates, a SOC 2 evidence package, and a CMMC-aligned report each take different preparation. Retests after remediation add effort. Ask every provider for a written scope, a list of deliverables, the reporting formats included, and the price of any retest, and compare quotes on the same scope.
What does a penetration test need from our team before it starts?
Plan for named contacts, access and rules of engagement before testing begins. Typical inputs include an agreed target list with owners, test accounts at each privilege level, network diagrams, change windows, emergency contacts for production systems, and written permission covering the hosts and cloud accounts in scope. Your team also needs to decide how findings are triaged and who approves remediation. For regulated work, confirm in writing which systems count as in scope for the cardholder data environment or the electronic protected health information systems, because that boundary determines what the test must cover.
Does DeployOpen issue a PCI DSS report, SOC 2 report or other audit report after testing?
No. DeployOpen runs security testing and prepares evidence, but it does not issue audit reports, attestations or certifications. A PCI DSS Report on Compliance and Attestation of Compliance come from a Qualified Security Assessor, and a SOC 2 report comes from a CPA firm. Independent auditors and certification bodies make those determinations. DeployOpen can plan the test, document findings and remediation, and organize evidence so your assessor can review it. Confirm with your assessor which evidence format they need before the engagement is scoped.
Which framework should drive the scope of our first penetration test?
Start with the framework that sets the strictest test requirement for your environment, then check whether the others can reuse the same evidence. PCI DSS sets a fixed yearly cadence for internal and external tests on systems in its scope, so it often drives the first scope for card environments. HIPAA's current Security Rule does not use the term penetration testing, while the proposed rule would require it every 12 months. CIS Safeguard 18.2 calls for external tests no less than annually, and NIST SP 800-53 CA-8 requires testing at an organization-defined frequency. Document each mapping in writing and confirm the frequency your auditor expects.
How DeployOpen scopes penetration testing for several audits
DeployOpen scopes one penetration test around the written requirements of every audit that will rely on it. Before work starts, we list each framework in play, the systems each one covers and the test type each one asks for, then agree the scope, deliverables and timeline in writing. The engagement is fixed-scope, so the agreed boundaries are the basis for any later change. For a team facing PCI DSS, SOC 2, HIPAA, DORA or NIST SP 800-53 CA-8 together, the scoping conversation is where differences in frequency, tester qualifications and system boundaries get resolved rather than discovered during the audit.
Testing covers applications and APIs, cloud and infrastructure, and the systems named in each requirement. Our security testing also includes AI systems and agents where they are in scope. Evidence is prepared against the controls and checks each auditor will ask about, so the test report, scope statement and remediation records can be traced to the specific requirements they support. DeployOpen does not issue audit reports, attestations or certifications. The qualified assessor, CPA firm, certification body or regulator that reviews the work makes that determination, so confirm with each of them in advance whether they accept an internal or third-party test and what they need to see.
Some requirements recur, such as the annual minimum in PCI DSS or a frequency set by your own risk analysis under the HIPAA proposed rule. Where that cadence applies, ongoing testing is available as a retainer, and the retainer scope should be written against the same requirement list. Ask for a quote that separates the one-time scoping and first test from any recurring work, and check that the frequency and triggers, such as significant infrastructure or application changes, are reflected in the agreed terms. For the full comparison of requirements across frameworks, see the compliance requirements compared hub.
How DeployOpen helps evaluate and implement
DeployOpen plans, runs and documents security testing as part of self-hosted platform work inside your own cloud accounts, data centers or air-gapped networks. For penetration testing requirements across frameworks, we start by agreeing in writing which systems, frequency triggers and evidence each audit needs, then build the test scope and handover around that.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- We map which systems fall under each framework's test trigger, such as significant change or a fixed review interval.
- We confirm the tester's qualifications and independence against each assessor's stated requirements before the work begins.
How we build
- We run internal and external tests with automated scanning plus expert-led exploitation of the systems in scope.
- Test methods follow recognized testing approaches, and we record which steps satisfy which control identifiers.
- We test after significant infrastructure or application changes, so the record matches the change dates your auditors will ask about.
How we hand over
- You receive a written report of findings, retest results and the scope, method and dates for each test.
- Evidence is organized by framework and control ID so one test can be presented to several audits.
- Gaps and open remediation items are documented so your assessor, not DeployOpen, decides how they affect your attestation.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers for recurring test cycles.
- Retainers can cover re-testing after remediation and updates to scope when systems or frameworks change.
- Confirm with your assessor which tester qualifications and report formats they accept before the first engagement.
