What a penetration test is
NIST SP 800-115 defines penetration testing as “security testing in which evaluators mimic real-world attacks in an attempt to identify ways to circumvent the security features of an application, system, or network.” The key words are “mimic real-world attacks”: a person tries to break in, the way an attacker would, within agreed limits.
That's different from a vulnerability scan. A scan is automated and broad: it checks many systems for known weaknesses. A penetration test is narrower and deeper: testers try to exploit weaknesses, chain them together and show what an attacker could actually reach. A sound testing program uses both, on different schedules.
Every test needs written authorization, an agreed scope and rules of engagement before anyone starts. Those documents also become part of the evidence you keep.
Types of penetration testing
Penetration tests are usually described by what they target. The right mix follows from where your sensitive data lives and how people and systems reach it.
Public references help set expectations. The OWASP Web Security Testing Guide (stable version 4.2) is a testing resource for web application developers and security professionals, and the OWASP API Security Top 10 (2023) names ten API risk categories, starting with broken object level authorization (API1:2023).
| Test type | What it targets | The question it answers |
|---|---|---|
| Web application | Authentication, sessions, authorization, input handling and business logic in a web app | Can someone abuse the application to reach data or functions they shouldn't? |
| API | The endpoints behind your apps and integrations, including object- and function-level authorization | Can a caller read or change objects that belong to someone else? |
| External network | Internet-facing hosts and services on your perimeter | What can an outsider reach and exploit from the internet? |
| Internal network | Systems reachable from inside, for example after a laptop or account is compromised | How far could an attacker move once inside? |
| Segmentation test | The controls that isolate a sensitive environment from other networks | Do the controls that separate in-scope systems from everything else actually hold? |
How often should you do a penetration test?
Set penetration testing frequency in two layers: a baseline cadence, plus extra tests when risk changes. A yearly cycle matches the floor PCI DSS sets and the interval the HIPAA proposal would set, so it's a reasonable baseline.
The Trust Services Criteria put the principle plainly in a CC4.1 point of focus: management “varies the scope and frequency of separate evaluations depending on risk.” In practice, that means writing test triggers into your testing policy. Triggers worth including:
- A major release that adds features, user roles or new ways of handling sensitive data
- New or changed authentication, authorization or payment flows
- Infrastructure changes such as a cloud migration, new network zones or changes to segmentation
- New integrations, public APIs or third-party components that handle sensitive data
- A merger, acquisition or new business line that connects networks
- A contract, customer or regulator that requires a test by a date
Scope follow-up tests to the change
A test after a release doesn't have to repeat everything. Scope it to what changed and what the change touches, and keep the full annual test for the broad view. A focused test soon after a risky change is often more useful than a second full test months later.
PCI DSS penetration testing requirements (11.4)
PCI DSS v4.0.1 is the one framework here with explicit penetration testing rules. Requirement 11.4 sets them out in parts:
- 11.4.1: a defined, documented and implemented methodology that uses industry-accepted approaches, covers the entire cardholder data environment (CDE) perimeter and critical systems, tests from inside and outside the network, validates segmentation and scope-reduction controls, and includes application-layer and network-layer testing.
- 11.4.2 and 11.4.3: internal and external penetration tests at least once every 12 months and after any significant infrastructure or application upgrade or change, by a qualified internal resource or qualified external third party, with organizational independence of the tester (not required to be a QSA or ASV).
- 11.4.4: exploitable vulnerabilities and security weaknesses found during testing are corrected according to the entity's assessment of the risk, and testing is repeated to verify the corrections.
- 11.4.5: if segmentation is used to isolate the CDE, penetration tests on segmentation controls at least once every 12 months and after any changes to segmentation controls or methods.
- 11.4.6: for service providers, the same segmentation tests at least once every six months and after any such changes.
Records PCI DSS expects
The methodology in 11.4.1 also covers retaining penetration testing results and remediation results for at least 12 months. Which requirements you validate, and on which form, depends on your validation route and what your acquirer or the payment brands require.
SOC 2 penetration testing requirements
SOC 2 has no penetration testing rule and no fixed interval. The Trust Services Criteria are criteria, not a control checklist, and the AICPA states that using them “does not require an assessment of whether each point of focus is addressed.”
Penetration testing does appear as a point of focus. Under CC4.1 (monitoring activities), management uses different types of ongoing and separate evaluations, and the list names penetration testing alongside vulnerability scans, security assessments and third-party assessments. Under CC7.1, a point of focus describes infrastructure and software vulnerability scans run periodically and after significant changes.
How you evaluate your controls is your decision; the CPA firm examines whether your controls meet the criteria you've chosen. If your risk assessment or customer commitments rely on penetration testing, the service auditor may ask to see the scope, the report and how findings were handled, so ask the CPA firm early what evidence it will look for.
HIPAA penetration testing requirements
The HIPAA Security Rule in force today doesn't mention penetration testing or vulnerability scanning. It does require an accurate and thorough risk analysis (45 CFR 164.308(a)(1)(ii)(A)) and a periodic technical and nontechnical evaluation, based first on the standards and then “in response to environmental or operational changes affecting the security of electronic protected health information” (164.308(a)(8)).
A penetration test is one way to produce evidence for that evaluation and to check the safeguards your risk analysis relies on. Whether you need one, and how often, follows from that analysis.
That may change. In January 2025, HHS proposed amending the Security Rule (90 FR 898). As proposed, covered entities and business associates would have relevant electronic information systems penetration tested by a qualified person at least once every 12 months, or more often if their risk analysis calls for it, and would run automated vulnerability scans at least once every six months. As of September 27, 2026, the proposed rule hasn't been finalized or withdrawn, so those intervals aren't requirements today.
ISO 27001 penetration testing
ISO/IEC 27001 sets requirements for an information security management system and doesn't name a penetration testing interval; frequency follows from your own risk decisions. You assess information security risks, decide how to treat them, compare the controls you need with the reference set in Annex A, and record the result in your Statement of Applicability.
If penetration testing is one of the ways you treat risk or check that controls work, set the interval in your own policy, follow it and keep the results. A certification body audits the management system you've documented and run, so an interval you write down and then miss works against you.
Contracts, customers and insurers
Some of the firmest testing deadlines come from outside any framework. Enterprise customers may write an annual test into a master services agreement or security addendum. Security questionnaires may ask when you last tested and whether you'll share a summary. Cyber insurance applications may ask about testing too.
Read the clause itself. Note what it requires (a test, an outside test, a summary letter, or remediation within a set time), which systems it covers, and by when. Put those dates in the same testing calendar as your framework obligations, so one well-scoped test can serve several needs.
Retests and the evidence to keep
A test isn't finished when the report arrives. Fix findings in order of risk, then retest to confirm the fixes work. PCI DSS makes retesting explicit in 11.4.4, and it's sound practice everywhere else. For each test, keep:
- The written authorization, scope and rules of engagement
- The methodology used, and the tester's qualifications and independence
- The full report, with findings ranked by risk
- Remediation decisions, including any accepted risks and who approved them
- Retest results showing which findings are closed