Pass your PCI DSS assessment
PCI DSS requires internal and external penetration testing under Requirement 11.4. Pentest Today produces the external half: a penetration test report for the cardholder data environment's publicly reachable systems. The internal test, segmentation testing under 11.4.5, and the quarterly ASV scan under 11.3.2 each need a separate engagement.
What a PCI DSS review asks for
PCI DSS protects cardholder data and explicitly requires both internal and external penetration testing at least annually.
What closes each requirement
| Control | What they ask | Evidence | Where it comes from |
|---|---|---|---|
| 11.4 · penetration testing | Proof that an organizationally independent tester assessed both the external perimeter and the internal network of the cardholder data environment within the past twelve months, and again after anything that materially changed it. | The penetration test report for the CDE's publicly reachable systems — each finding rated by severity and tied to the asset it was found on, a CVSS v3.1 vector and base score attached wherever scoring was done, and a documented fix on the findings that got one — plus the retest report that restates each finding as fixed or not fixed. Testing runs only against targets that resolve to a public address, so this is the external half of 11.4; the internal test has to come from a tester positioned inside the network. | The pentest workflow's client-ready PDF and the retest workflow, for the externally facing part of the scope only. |
| 11.4.5 / 11.4.6 · segmentation testing | If segmentation is what keeps part of the network out of the CDE's scope, show that the controls enforcing that separation were actually tested — not just drawn as separate on a diagram. | Not produced here. Segmentation testing needs a tester positioned inside the network, sending traffic across the boundary from an out-of-scope segment and recording which control stopped it. This product's testing runs only against targets that resolve to a public address, so it has nothing to say about reachability between internal segments. Source this from a firm that performs internal testing, and have it re-run after any change to the segmentation controls. | A separate internal engagement. Not this product. |
| 11.3 · vulnerability scanning | Internal vulnerability scans at least quarterly and after significant change (11.3.1), plus an external scan at least quarterly by a PCI SSC Approved Scanning Vendor (11.3.2) and again after significant change (11.3.2.1). | Neither half of 11.3 is produced here. The external quarterly scan has to come from a PCI SSC Approved Scanning Vendor, which this product is not; the internal quarterly scan needs a scanner positioned inside the network, and this product's scans run only against publicly reachable targets. The scans here cover the externally reachable surface, which is evidence toward 11.4, not 11.3. | Not this product. An Approved Scanning Vendor for the external scan; a scanner inside the network for the internal one. |
| 6.3 · identifying and addressing vulnerabilities | That vulnerabilities are actively found and ranked by risk, and that critical and high-severity ones are patched inside a defined window rather than sitting in a backlog. | The pentest and scan findings give the ranked, dated list; the Vulnerability Management Policy's remediation SLA — seven days for critical, thirty for high — gives the documented patch window a QSA checks the dates against. | The pentest/scan workflow for the findings, the policy pack's Vulnerability Management Policy for the SLA. |
| 1.2 · network security controls | A current diagram of every connection between the CDE and other networks, and of the cardholder data flows themselves — the diagram drawn for last year's assessment doesn't count once the network has changed. | The generated system architecture and data-flow diagram, regenerated from the current intake rather than reused from a prior assessment — so a segment added since the last drawing actually shows up on it. The diagram and the pentest's approved-target list are separate artifacts; keeping them pointed at the same boundary is still the reviewer's job, not something the shared intake guarantees on its own. | The architecture diagram generator, drawn from the intake's cloud provider, hosting setup, and vendor fields. |
| 12.10 · incident response | A documented plan specific enough to run during an actual incident — roles, an escalation path, and a recovery process — not a policy that exists only to be shown to an assessor. For a payment environment, that plan has to cover a suspected compromise of cardholder data specifically, not just security events in general. | The Incident Response Policy, read for who is named to run it and whether the process it describes reaches past detection into recovery and a post-incident review, rather than stopping once something has been noticed. | The policy pack, drawing its named contact and monitoring detail from your intake instead of a placeholder title. |
What the report actually contains
Illustrative example, written in the format the product generates. Not taken from a customer engagement.
How this review actually runs
A PCI DSS assessment runs through a QSA if you file a Report on Compliance, or through self-assessment against a Self-Assessment Questionnaire if your acquirer allows it — which track applies depends on transaction volume and is the acquirer's call, not yours. The requirement text is identical either way; only who signs off changes.
Scoping happens before any testing does, and it decides more than any technical step that follows: which systems store, process, or transmit cardholder data, plus every system that can reach one of them without a network security control in the way. That second group — adjacent to the boundary rather than inside it — is where most CDEs turn out larger than the network diagram claims.
The penetration test covers the CDE and its perimeter under Requirement 11.4, at least annually and again after a significant change. Where segmentation is used to shrink the CDE, 11.4.5 tests whether that isolation actually holds instead of accepting the diagram at face value — and that test, like the internal penetration test under 11.4.2, is run from inside the network, which this product does not do. Only the external penetration test under 11.4.3, the CDE's publicly reachable systems, is what the pentest here covers; the internal test and the segmentation test each need a separate engagement. Findings then move through remediation and a retest that restates each one as fixed or not fixed, the same trail a QSA samples later.
It stalls when the tested boundary doesn't match the CDE the QSA has already walked through on their own: a segment the client called out of scope turns out reachable, and the assessment restarts from the network diagram rather than from the findings.
What gets this sent back
Scan
Authenticated and external scans across web, API, and cloud surface the issues before an assessor does — de-duped, triaged, and mapped to CVE/CVSS.
Pentest
Approved-target scans become a client-ready pentest report: validated findings, evidence, reproduction steps, remediation, and the retest letter auditors accept.
Policy Generator
Generate the policies and system architecture diagrams the review expects — access control, cryptography, incident response — pre-mapped to controls.
Start your Pentest
Our agent swarm and human experts test your endpoints and deliver an audit, fast.
NIST CSF
The NIST Cybersecurity Framework organizes security around Identify, Protect, Detect, Respond, and Recover.
FedRAMP
FedRAMP authorizes cloud services for U.S. federal use, built on NIST 800-53 controls and requiring penetration testing.
CMMC
CMMC verifies that defense contractors protect Controlled Unclassified Information (CUI) per NIST 800-171.
Meta TPA
Meta requires apps and vendors that access Platform Data to complete an annual Third-Party Assessment (formerly the Data Protection Assessment) with an approved assessor.
Google VSA
Google's Vendor Security Assessment reviews how suppliers protect Google and user data before and during an engagement.
Microsoft SSPA
Microsoft's Supplier Security and Privacy Assurance (SSPA) program requires suppliers handling Microsoft personal data to attest to the Data Protection Requirements (DPR).
PCI DSS, answered
Is penetration testing mandatory for PCI DSS?
Requirement 11.4 mandates internal and external penetration testing at least annually and after any significant change to the environment. The report has to be scoped specifically to the cardholder data environment — a test of the wrong systems doesn't satisfy the requirement, even when the testing itself was thorough.
Does Pentest Today's scanning satisfy the ASV requirement?
Pentest Today's scanning is not a substitute for the ASV requirement. Requirement 11.3.2 requires the quarterly external scan to be performed by a PCI SSC-approved scanning vendor, which Pentest Today is not. Its scanning supports internal vulnerability management and the penetration test; the ASV scan stays a separate obligation sourced elsewhere.
What is segmentation testing, and do I need it?
Segmentation testing checks whether the network controls separating your cardholder data environment from the rest of the network actually hold, not just whether a diagram shows them separated. Requirement 11.4.5 requires it for any environment that relies on segmentation to reduce PCI scope, at least annually and after changes.
What's the difference between a ROC and an SAQ?
A Report on Compliance is a full assessment performed by a QSA, typically required at higher transaction volumes. A Self-Assessment Questionnaire lets a merchant attest to the same requirements themselves, where their acquirer permits it. Which track applies is set by the acquiring bank based on volume, not chosen by the merchant.
How is the scope of a PCI pentest decided?
Scope starts with every system that stores, processes, or transmits cardholder data, then extends to anything that can reach one of those systems without a network security control in between. Getting that second group wrong is the most common reason a completed pentest still doesn't match the CDE a QSA has scoped.
What triggers a PCI pentest outside the annual cycle?
Requirement 11.4 requires re-testing after any significant change to the CDE — a new network segment, a changed firewall ruleset, a new system handling cardholder data. Segmentation testing under 11.4.5 has its own trigger: any change to the segmentation controls themselves, independent of whether the annual test is already due.
Is the pentest a real test or just a scanner dump?
Both scanning and AI triage are scoped to your approved targets, and every finding is reviewed and signed off by a human before delivery — so the report reflects verified findings, not raw scanner noise.
How fast can I get a report?
Most reports turn around in hours, not weeks. You connect an approved target, we scan and verify, and you export a client-ready report and policy pack.
Get the evidence for your PCI DSS review this week.
Start a scan on an approved target and walk in with the report, policies, and diagrams already done.