Excession Labs Talk to the lab

Blog ·

How often must you pentest? What PCI DSS, HIPAA, ISO 27001 and SOC 2 say

PCI DSS sets an interval for penetration testing: once every 12 months and after a significant change. HIPAA, ISO 27001 and SOC 2 set none in the text we could read. A HIPAA rule proposed in January 2025 would add one, also 12 months, but it is not final.

Below, each framework speaks in its own words, with the clause number, the interval if there is one, and the events that call for an extra test. Where we could not read a standard, we say so. Every source has a URL and the date we read it in the source list.

Summary table

Pentest frequency by framework (sources read 12 November 2026)
Framework and clauseNames a pentest interval?IntervalTrigger events
PCI DSS v4.0.1, 11.4.2 and 11.4.3Yes (see the note on sources below)At least once every 12 monthsA significant infrastructure or application upgrade or change. You define "significant".
HIPAA Security Rule, 45 CFR 164.308(a)(8)No. It requires a periodic evaluation.None"environmental or operational changes affecting the security of electronic protected health information"
HIPAA proposal of January 2025, 164.312(h)(2)(iii)Yes, but only proposedAt least once every 12 months, or more often if your risk analysis says soYour risk analysis
ISO/IEC 27001:2022 Annex A 8.8, ISO/IEC 27002:2022Not verified. The text is paywalled.Not verifiedNot verified
SOC 2 (AICPA 2017 criteria), CC4.1 and CC7.1Names a pentest as an example onlyNone. Frequency varies "depending on risk".CC7.1 names "any significant change in the environment" for vulnerability scans
NIST SP 800-53 Rev 5, CA-8Control exists, interval left to you"organization-defined frequency"None stated
FedRAMPYes, in 2022 guidanceAt least every 12 months in continuous monitoringFirst test no more than 6 months before the assessment report
DORA, Article 26 (EU)Yes, for threat-led testingAt least every 3 yearsThe authority may raise or lower the frequency

PCI DSS: 12 months and after a significant change

Requirement 11.4 of PCI DSS v4.0.1 holds the penetration testing rules. 11.4.1 covers the methodology, 11.4.2 internal testing and 11.4.3 external testing.

First, a limit on what we can quote. The PCI Security Standards Council publishes the standard behind a license click-through, and a direct PDF link returned an access error to our script. We did not accept the license. So we have not read 11.4.2 or 11.4.3. We quote two Council files that need no agreement.

The Council's Penetration Testing Guidance (version 1.1, September 2017) was written for PCI DSS 3.2.1, where pentests sat under 11.3. Its table sets scans against pentests:

  • Vulnerability scans: "At least quarterly and after significant changes"
  • Penetration tests: "At least annually and upon significant changes"

On "significant", the guidance says "a significant change is not prescribed by PCI DSS" and "If the change could impact the security of the network or allow access to cardholder data, it may be considered significant by the entity."

The Council's Summary of Changes from 3.2.1 to 4.0 (May 2022) says of 11.4.1: "Penetration testing results are retained for at least 12 months." It says findings under 11.4.4 are corrected "in accordance with the entity's assessment of the risk posed by the security issue."

For the v4.0.1 interval we have only vendor pages. Software Secured, Strobes and EIC Secure each give the same reading: 11.4.2 and 11.4.3 require testing at least once every 12 months and after a significant infrastructure or application change. They paraphrase, so we do not put their words in quotation marks. Before you cite the clause in an audit, read it in your copy of the standard or ask your QSA.

In practice, a pentest is due every 12 months and after a change you have defined as significant. Scans are a separate duty. See vulnerability scanner vs penetration test for the difference.

HIPAA: "periodic" today, 12 months if the proposal becomes final

The rule in force

The evaluation standard is 45 CFR 164.308(a)(8): "Perform a periodic technical and nontechnical evaluation, based initially upon the standards implemented under this rule and, subsequently, in response to environmental or operational changes affecting the security of electronic protected health information, that establishes the extent to which a covered entity's or business associate's security policies and procedures meet the requirements of this subpart."

It does not mention penetration testing and sets no interval. The risk analysis in 164.308(a)(1)(ii)(A) asks for "an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information." A pentest can feed that analysis. HIPAA does not require one by name. On 12 November 2026 the eCFR showed 164.308 last amended on 30 December 2016.

The January 2025 proposal

On 6 January 2025 HHS published a notice of proposed rulemaking (90 FR 898). It is a proposal, not law. Comments closed on 7 March 2025. Proposed 164.312(h)(2)(iii) reads: "Penetration testing must be performed at least once every 12 months or in accordance with the covered entity's or business associate's risk analysis required by Sec. 164.308(a)(2), whichever is more frequent." A "qualified person" would do the test. The proposal also has automated vulnerability scans at least every six months.

We found no final rule as of 12 November 2026. The Federal Register lists one document under this rule's identifier (RIN 0945-AA22): the proposal. The Unified Agenda entry shows "Long-Term Actions" and a final action date of 07/00/2027. An agenda date is a plan and can move. Treat 12 months as a likely future number, not a duty today.

ISO 27001: what the public text shows

ISO/IEC 27001:2022 and ISO/IEC 27002:2022 are sold, and we did not buy them. ISO's public page for 27001:2022 shows the title, edition and status. It shows no clause text, and a search of the page found neither "penetration" nor "8.8". So we quote no ISO sentence.

ISMS.online, a vendor of certification software, says the guidance for control 8.8 (management of technical vulnerabilities) includes "Carry out regular, documented penetration tests". That is a vendor paraphrase and names no interval. We found no public ISO text that sets an interval, and we could not read the paywalled text to confirm there is none. Treat the ISO interval as unverified and ask your certification body what they expect.

SOC 2: no interval, and a pentest is only an example

The AICPA criteria are covered in Does SOC 2 require a penetration test?. For frequency:

  • CC4.1: "The entity selects, develops, and performs ongoing and/or separate evaluations to ascertain whether the components of internal control are present and functioning."
  • Point of focus: "Management varies the scope and frequency of separate evaluations depending on risk."
  • Point of focus: "Separate evaluations are performed periodically to provide objective feedback."
  • Point of focus: "Management uses a variety of different types of ongoing and separate evaluations, including penetration testing, independent certification made against established specifications (for example, ISO certifications), and internal audit assessments."
  • CC7.1, scans: "The entity conducts vulnerability scans designed to identify potential vulnerabilities or misconfigurations on a periodic basis and after any significant change in the environment."

"Penetration" appears once in the document we read, and no line sets an interval for it. The trigger phrase "any significant change in the environment" sits in the scan line. The AICPA says using the criteria "does not require an assessment of whether each point of focus is addressed."

Linford & Company, a CPA firm, wrote on a page updated 11 August 2026: "At a minimum, annually for compliance purposes." That is an auditor's view, not criteria text. A customer contract can also set the interval.

NIST, FedRAMP and DORA

NIST SP 800-53 control CA-8 reads: "Conduct penetration testing [Assignment: organization-defined frequency] on [Assignment: organization-defined system(s) or system components]." The frequency is a blank for you to fill. The guidance adds that "Risk assessments guide the decisions on the level of independence required for the personnel conducting penetration testing."

FedRAMP's Penetration Test Guidance (version 3, 30 June 2022), section 7.0, says: "Once within the continuous monitoring phase of the FedRAMP process, additional penetration testing activities must be performed at least every 12 months, unless otherwise approved by an authorizing body with documented rationale." The first test "must be performed no more than 6 months prior to the submission of the SAR." FedRAMP's 2026 page for CA-08 now says "Penetration testing is part of vulnerability detection and is subject to the Vulnerability Detection and Response rules." We did not read those rules for an interval, so check them if you sell to the US government.

DORA, the EU's Regulation 2022/2554 for financial entities, says in Article 26(1) that they "shall carry out at least every 3 years advanced testing by means of TLPT", meaning threat-led penetration testing. The authority "may, where necessary, request the financial entity to reduce or increase this frequency." Article 24(6) adds a yearly duty. Financial entities other than microenterprises "shall ensure, at least yearly, that appropriate tests are conducted on all ICT systems and applications supporting critical or important functions."

A rule for teams that ship weekly

PCI leaves "significant change" to you. HIPAA says "environmental or operational changes". SOC 2 says "depending on risk". If you release weekly, one yearly test leaves most of the year's changes untested. No framework above says what to do. The steps below are ours, and your auditor decides what they accept.

  1. Write down what "significant" means for your product. Examples: a new login or session flow, a new user role, a new public API, a new integration that holds customer data, a change to the hosting layout.
  2. Put the definition in your security policy. Auditors can then test you against your own words.
  3. Run a full test every 12 months. Run a scoped test of the changed area when a release meets your definition.
  4. Log the releases that did not meet the definition, with the reason.
  5. Keep the report, the fix tickets and the retest note for each test.

If you fall under both PCI DSS and SOC 2, the PCI interval is the only fixed one, so use it.

FAQ

How often should penetration testing be done?

PCI DSS says once every 12 months and after a significant change. HIPAA, ISO 27001 and SOC 2 set no interval in the text we could read. Annually is the common floor that auditors and contracts ask for.

Does HIPAA require a penetration test?

Not by name. The rule in force requires a periodic evaluation and a risk analysis. The January 2025 proposal would require a test every 12 months. It is not final.

Does a vulnerability scan satisfy PCI DSS?

No. The Council's guidance treats scans and pentests as two activities with two intervals.

What counts as a significant change?

No framework defines it. The PCI Council says the entity decides, and that a change which could affect network security or access to cardholder data may count.

Who can run the test?

The Council's guidance says qualified internal staff or a qualified third party may test, "as long as they are organizationally independent." NIST CA-8(1) asks for an independent team. Confirm the exact rule with your auditor.

Next step

To scope a test, read about penetration testing, external penetration testing or web application penetration testing. The sample report shows a finished report. For how providers charge, see penetration testing cost in 2026.

Sources and dates checked

We read all pages on 12 November 2026. Standards change, so check the current version before you quote one in an audit.

The same list, with the verbatim text, is in the evidence file.