Internal Penetration Testing

PCI DSS 4.0.1 requires you to perform internal penetration testing at least once every 12 months and again after any significant infrastructure or application upgrade or change, using your defined methodology (PCI DSS v4.0.1 Requirement 11.4.2). To operationalize it, lock scope to the CDE and connected systems, define “significant change” triggers, run tests with proven independence and competence, and retain clean evidence of findings and remediation.

Key takeaways:

• You need an internal pen test on a recurring cadence and after significant changes, following your documented methodology (PCI DSS v4.0.1 Requirement 11.4.2).
• Your biggest operational risk is missing “significant change” triggers; tie the requirement to change management so tests are automatically initiated.
• Evidence matters as much as execution: keep scope, methodology, results, and remediation proof in an assessor-ready package.

“Internal penetration testing requirement” in PCI programs usually fails for one of three reasons: the scope is fuzzy, “significant change” is undefined, or remediation evidence is incomplete. PCI DSS 4.0.1 Requirement 11.4.2 is simple on paper: perform internal penetration testing per your methodology at least annually, and after significant upgrades or changes (PCI DSS v4.0.1 Requirement 11.4.2). In practice, it forces you to build an operating rhythm that connects security testing to how engineering actually ships changes.

As the Compliance Officer, CCO, or GRC lead, your job is not to run exploits. Your job is to ensure the organization can prove a consistent, repeatable internal penetration testing program that covers the right systems, is triggered at the right times, produces actionable findings, and closes the loop with tracked remediation. This page gives you requirement-level implementation guidance you can hand to Security and Engineering, plus the evidence checklist and audit questions you should expect from a QSA or internal audit team. Source references: PCI DSS document library and overview materials (PCI DSS v4.0.1; PCI DSS v4.0.1 Requirement 11.4.2; Just Published: PCI DSS v4.0.1).

Regulatory text

PCI DSS 4.0.1 Requirement 11.4.2 states: “Internal penetration testing is performed per the entity's defined methodology at least once every 12 months and after any significant infrastructure or application upgrade or change.” (PCI DSS v4.0.1 Requirement 11.4.2)

Operator interpretation (what you must do):

1. Define and document your internal penetration testing methodology (your standard approach, rules of engagement, testing depth, and reporting format).
2. Run internal penetration tests at least annually against the in-scope environment.
3. Run internal penetration tests again after significant change, not just on a calendar schedule.
4. Be able to show evidence that the testing occurred, what was in scope, what was found, and how findings were handled.

Plain-English interpretation

Internal penetration testing is a controlled attempt to break into your environment from the “inside” perspective: a compromised workstation, a malicious insider, or an attacker who has already gained a foothold. PCI’s focus is outcome-driven: you must periodically validate that internal defenses still hold, and you must re-validate after major changes that could invalidate prior test results (PCI DSS v4.0.1 Requirement 11.4.2).

For compliance purposes, “internal” should map to realistic internal attack paths into the cardholder data environment (CDE) and any connected systems that could affect CDE security. Your test should be repeatable (methodology), scoped, authorized, and connected to remediation.

Who it applies to

Entities: Merchants, service providers, and payment processors that store, process, or transmit account data, and service providers whose people, processes, or systems can affect the security of the CDE (PCI DSS v4.0.1 Requirement 11.4.2; PCI DSS v4.0.1).

Operational context (where it bites):

• You have an in-scope CDE or segments connected to it.
• You make infrastructure or application changes that can alter security posture (network changes, IAM changes, platform migrations, code releases affecting payment flows).
• You rely on third parties (for example, managed services) that can change systems in or connected to your CDE; your program still needs to trigger testing when changes are significant.

What you actually need to do (step-by-step)

1) Set scope boundaries that an assessor will accept

Create a written scope statement that answers:

• What networks, VLANs, VPCs, subnets, hosts, and applications are in-scope for internal pen testing.
• How you determined scope (tie it to your PCI scoping and data-flow documentation).
• What is explicitly out of scope and why (for example, isolated corporate networks with no connectivity path).

Practical tip: If you cannot explain the attack path assumptions (“from where to where”), internal pen tests drift into generic vulnerability testing and assessors will push back.

2) Define your internal penetration testing methodology (and keep it stable)

Your methodology document should be short but explicit:

• Objectives: validate segmentation controls, lateral movement resistance, access control robustness, and privilege escalation paths into the CDE.
• Preconditions: approved rules of engagement, allowed tools, test windows, and safe-handling requirements.
• Test activities: discovery, enumeration, exploitation attempts, post-exploitation constraints, and validation steps.
• Evidence expectations: required screenshots/log extracts, command outputs, and report sections.
• Severity model and triage: how findings are rated and how owners/SLAs are assigned.
• Independence and competence: who performs the test and how conflicts are avoided.

PCI DSS 11.4.2 requires testing “per the entity’s defined methodology,” so the methodology must exist before you claim compliance (PCI DSS v4.0.1 Requirement 11.4.2).

3) Operationalize the cadence: “annual” plus “significant change” triggers

The requirement has two separate triggers:

• Periodic trigger: at least once every 12 months (PCI DSS v4.0.1 Requirement 11.4.2).
• Event trigger: after significant infrastructure or application upgrade/change (PCI DSS v4.0.1 Requirement 11.4.2).

Your job is to remove judgment calls at the moment of change. Build a “significant change” decision matrix and embed it in change management.

Example “significant change” triggers (adapt to your environment):

• Network segmentation changes affecting CDE boundaries (firewall rules, routing, NAC changes).
• Identity and access model changes (SSO/IAM redesign, PAM rollout, privilege model changes).
• Major platform migrations (new hosting environment, new container orchestration, major OS changes).
• Payment application changes that affect authn/authz, encryption, data flows, or admin interfaces.
• New remote access patterns into CDE (jump hosts, VPN architecture changes).

Implementation requirement: Document the trigger definition and show how changes are screened and escalated into a pen test request.

4) Execute the internal pen test with tight governance

Treat the pen test as a controlled engagement:

• Written authorization, scope, and timing.
• Identified points of contact and escalation path for production impact.
• Evidence capture expectations (what the tester must save, what must be redacted).
• Final report delivery to Security and Compliance stakeholders.

If a third party runs the test, manage it as a third-party engagement: ensure contractual permission, confidentiality, and explicit scope boundaries.

5) Triage findings and drive remediation to closure

A pen test report alone does not close the control. Build a closure workflow:

• Create tickets for each finding with an owner, due date, and remediation plan.
• Track exceptions formally if remediation is deferred (with compensating controls and approval).
• Re-test or otherwise validate fixes for high-risk findings before you declare completion.

6) Package evidence for assessors (make it easy to verify)

Prepare an “assessor-ready” bundle per test:

• Methodology version used.
• Scope and asset list.
• Rules of engagement and authorization.
• Final report and raw evidence excerpts.
• Remediation tracking and closure proof.

This is where tools like Daydream fit cleanly: use it to centralize the methodology, test schedule, scope maps, change triggers, and remediation tickets so the “annual + significant change” requirement is visible, owned, and auditable without chasing screenshots across tools.

Required evidence and artifacts to retain

Maintain a controlled set of artifacts for each internal penetration test cycle:

Governance

• Approved internal penetration testing methodology (versioned).
• Pen test plan or engagement letter (scope, dates, constraints, approvals).
• Tester qualification/independence record (internal role separation or third-party SOW).

Execution

• Scope evidence: in-scope IP ranges, hostnames, apps, diagrams, segmentation assumptions.
• Testing notes/evidence excerpts: command output, screenshots, tool logs (sanitized as needed).
• Final penetration test report with findings, severity, affected assets, reproduction steps, and recommendations.

Remediation

• Tickets for each finding, ownership assignment, and status history.
• Evidence of fixes (config diffs, change records, screenshots, deployment records).
• Retest results or verification notes showing closure.

Change-trigger linkage

• Change management records showing the “significant change” decision and resulting pen test initiation (or documented rationale if not significant).
• An exceptions register if change-triggered testing is deferred, with approvals.

Common exam/audit questions and hangups

Expect QSAs and auditors to probe these areas:

1. “Show me your methodology.” If it’s a slide deck without depth, you will spend time clarifying what you actually do (PCI DSS v4.0.1 Requirement 11.4.2).
2. “What counts as significant change here?” Auditors look for a definition and a consistent operational trigger, not ad hoc decisions (PCI DSS v4.0.1 Requirement 11.4.2).
3. “How did you decide scope?” They will compare your pen test scope to your PCI scope, CDE diagrams, and data flows.
4. “Who performed the test and were they independent?” Be ready to show organizational separation or third-party independence.
5. “Did you remediate, or just report?” Expect sampling of findings through closure evidence, not only the report.

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails	How to avoid it
Treating vulnerability scans as a “pen test”	Pen tests require adversarial validation, not just automated findings	Keep a distinct pen test report and methodology aligned to internal attack paths (PCI DSS v4.0.1 Requirement 11.4.2)
No definition of “significant change”	Change-triggered requirement becomes untestable	Publish a decision matrix and integrate it into change management intake (PCI DSS v4.0.1 Requirement 11.4.2)
Testing only a subset without rationale	Assessor questions whether CDE paths were tested	Tie scope to CDE boundaries, segmentation, and connectivity assumptions
Findings tracked informally	You can’t prove closure	Use ticketing with audit-ready history and attach verification evidence
Evidence is scattered across emails	You lose operating proof during assessment	Store artifacts in a controlled repository; keep a single engagement packet per test

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this specific requirement. Practically, the risk is operational: if internal penetration testing is incomplete or not reviewed, suspicious activity and control failures can go undetected, and you may lack operating evidence during PCI scoping, assessor testing, and remediation follow-up (PCI DSS v4.0.1 Requirement 11.4.2).

A practical 30/60/90-day execution plan

First 30 days (stabilize the requirement)

• Confirm PCI scope boundaries for internal pen testing (CDE and connected systems).
• Publish a versioned internal penetration testing methodology aligned to your environment (PCI DSS v4.0.1 Requirement 11.4.2).
• Define “significant change” triggers and add a mandatory field/check to change tickets.
• Choose execution model (internal team with separation, or third-party) and create a standard rules-of-engagement template.

Next 60 days (run and prove one complete cycle)

• Schedule and execute the internal pen test against the approved scope.
• Deliver the final report to Security + Compliance, and open remediation tickets for each finding.
• Build an evidence packet and store it centrally (methodology, scope, report, raw excerpts, tickets).

By 90 days (make it repeatable and change-driven)

• Validate that change management reliably triggers pen test review after significant changes.
• Establish a recurring calendar reminder for annual testing and define ownership (Security executes; GRC verifies evidence completeness).
• Add a management review checkpoint: confirm remediation closure and document any approved exceptions.

Frequently Asked Questions

Does PCI DSS require internal penetration testing even if we outsource payment processing?

If your systems or people can affect the security of the CDE, the requirement can still apply to your environment and connected systems (PCI DSS v4.0.1). Confirm applicability based on your PCI scope and service provider responsibilities.

What qualifies as a “significant infrastructure or application upgrade or change”?

PCI DSS 11.4.2 requires you to test after significant changes, but you must define “significant” in your context and apply it consistently (PCI DSS v4.0.1 Requirement 11.4.2). The best operational approach is a decision matrix tied to segmentation, access control, hosting platform, and payment-flow changes.

Can the internal security team perform the internal penetration test?

The requirement states testing must follow your defined methodology on the required cadence (PCI DSS v4.0.1 Requirement 11.4.2). If you use internal staff, document competence and manage conflicts so the test is credible and assessable.

Do we need to re-test after remediation?

PCI DSS 11.4.2 focuses on performing the pen test on schedule and after significant change (PCI DSS v4.0.1 Requirement 11.4.2). From an auditability standpoint, you should verify closure for material findings and retain proof, because assessors commonly sample issues through to remediation.

How do we prove compliance if the pen test artifacts contain sensitive exploit details?

Keep a controlled full report with restricted access, and produce a sanitized assessor version that still shows scope, methods, findings, and remediation tracking. Maintain an evidence index so you can prove completeness without over-sharing.

We had many minor releases. Do we need a pen test after every deployment?

The trigger is “significant” change, so your program should classify changes and only trigger testing when the change could materially alter attack paths or controls (PCI DSS v4.0.1 Requirement 11.4.2). Put the classification in change management so it’s consistent and reviewable.