PCI DSS Compliance
PCI DSS 4.0.1 requires organizations that handle cardholder data to develop software securely and test it regularly.
Learn how ImmuniWeb helps you meet Requirements 6 and 11.
Payment Card Industry Data Security Standard (PCI DSS) Compliance
What Is PCI DSS?
PCI DSS defines technical and operational requirements to protect cardholder data (CHD) and sensitive authentication data wherever it is stored, processed or transmitted. Its 12 requirements are grouped into six control objectives covering network security, data protection, vulnerability management, access control, monitoring and security policy.
Version 4.0 marked a shift in philosophy: security is treated as a continuous, business-as-usual process rather than an annual event. Organizations validate compliance through a Self-Assessment Questionnaire (SAQ) or a Report on Compliance (ROC), and define their cardholder data environment (CDE) as the scope of assessment.
See how ImmuniWeb helps you meet PCI DSS Requirements 6 and 11— secure development and regular testing of your payment applications. Request a demo · or run a free Community Edition test.
Who Must Comply with PCI DSS?
PCI DSS applies to every organization in the payment chain:
- Merchantsof every size that accept payment cards (validation level depends on transaction volume).
- Service providers that store, process or transmit cardholder data on behalf of others.
- Any entity whose systems could impact the security of the cardholder data environment (CDE).
Public-facing web applications and payment pages are squarely in scope and must be protected and tested.
Key PCI DSS Requirements for Application Security
Two of the twelve requirements drive most application-security work:
- Requirement 6 — Develop and maintain secure systems and software: secure software development, timely patching, identifying and managing vulnerabilities, and protecting public-facing web applications against attacks (including payment-page script controls in 6.4.3).
- Requirement 11 — Test security of systems and networks regularly: internal and external vulnerability scans (11.3) and internal and external penetration testing (11.4) at least annually and after significant changes, plus payment-page change detection (11.6).
PCI DSS Security Requirements in Depth
Requirement 6 — Secure Systems and Software
Requirement 6 expects a secure software development life cycle: software developed following secure coding practices, vulnerabilities identified and risk-ranked, and public-facing web applications protected against the OWASP Top 10. Sub-requirement 6.4.3 adds controls over scripts loaded on payment pages to counter web-skimming (Magecart) attacks.
Requirement 11 — Regular Security Testing
Requirement 11 mandates regular vulnerability scanning (11.3) and penetration testing (11.4) — internal and external, at least annually and after significant changes — with exploitable findings corrected and testing repeated to verify the fixes.
Common Web & Mobile Application Risks to Address
Payment applications are a prime target. The web vulnerabilities PCI DSS expects you to prevent and test for map closely to the OWASP Top 10:
- Broken Access Control — users reaching data or actions they should not.
- Cryptographic Failures — weak or missing encryption exposing sensitive data.
- Injection —SQL, command or other injection via unvalidated input.
- Insecure Design — missing security controls by design, not just by bug.
- Security Misconfiguration — default, incomplete or unsafe configuration.
- Vulnerable & Outdated Components — unpatched libraries and frameworks.
- Identification & Authentication Failures — weak login, session or credential handling.
- Software & Data Integrity Failures — untrusted updates, insecure CI/CD pipelines.
- Security Logging & Monitoring Failures — attacks going undetected.
- Server-Side Request Forgery (SSRF) — the server tricked into making malicious requests.
For mobile apps, the OWASP Mobile Top 10 is the equivalent reference (insecure data storage, insecure communication, weak cryptography, and so on). Reliably finding these issues requires testing the running application, not just a documentation review.
How to Approach PCI DSS Application Security with ImmuniWeb
- Scope the CDE.Map internet-facing applications, payment pages and APIs in scope with ImmuniWeb Discovery.
- Develop securely (Req 6). Use Neuron and Continuous to find and fix vulnerabilities across the SDLC.
- Penetration test (Req 11.4) web and mobile applications with On-Demand and MobileSuite — at least annually and after significant changes.
- Vulnerability scan (Req 11.3)regularly with Neuron.
- Remediate and retest with clear, zero-false-positive reports suitable for your QSA/ROC or SAQ.
- Keep testing continuously with Continuous to satisfy v4.0.1's business-as-usual model.
How ImmuniWeb Helps You Achieve PCI DSS Compliance
ImmuniWeb supports the PCI DSS application-security requirements with penetration testing and scanning that produce assessment-ready evidence.
| Requirement | What it requires | ImmuniWeb products |
|---|---|---|
| Req 6.2 / 6.3 | Develop software securely; identify and manage vulnerabilities. | On-Demand, Neuron, Continuous |
| Req 6.4 | Protect public-facing web applications against attacks. | On-Demand, Neuron, Continuous |
| Req 11.3 | Internal and external vulnerability scanning. | Neuron, Discovery |
| Req 11.4 | Internal and external penetration testing. | On-Demand, MobileSuite |
ImmuniWeb On-Demand delivers manual, compliance-ready web application penetration testing; MobileSuite covers mobile apps; Neuron and Neuron Mobile provide automated scanning; Continuous embeds testing into CI/CD; and Discovery maps the external attack surface to keep the CDE scope accurate.
PCI DSS vs International Frameworks
If you already work to international standards, the same ImmuniWeb testing supports all of them:
| Framework | Application-security angle | How ImmuniWeb maps |
|---|---|---|
| PCI DSS 4.0.1 | Req 6 (secure dev) & Req 11 (testing) | Web/mobile pentest + vulnerability scanning |
| ISO/IEC 27001 | Annex A technical controls | Testing as control evidence |
| NIST CSF 2.0 | Protect / Detect functions | Application testing & monitoring |
| OWASP ASVS | Verification levels for web apps | Testing aligned to ASVS requirements |
Penetration Testing vs Security Scanning
Both are needed. Automated scanning (DAST) gives broad, frequent coverage and is ideal for continuous testing in CI/CD; manual penetration testing finds business-logic and complex vulnerabilities that scanners miss and produces the depth auditors and regulators expect. Combine continuous scanning with periodic manual penetration testing, and re-test after significant changes.
Compliance Checklist (Application Security)
- Cardholder data environment (CDE) scoped, including web/payment pages
- Secure SDLC in place (Requirement 6)
- Public-facing web apps protected and tested
- Vulnerability scans performed regularly (Req 11.3)
- Penetration testing at least annually and after significant changes (Req 11.4)
- Payment-page script and change controls (6.4.3 / 11.6)
- Findings remediated and re-tested; evidence retained for assessment
Why PCI DSS Compliance Matters
PCI DSS is enforced contractually by the payment card brands and acquiring banks. Non-compliance can mean monthly fines, higher transaction fees, and — after a breach — significant liability and even loss of the ability to process card payments.
Web-skimming and application attacks against payment pages remain a leading cause of cardholder-data breaches, which is why Requirements 6 and 11 put application testing front and centre.