Maria Chen had eleven minutes before her board call when the alert came in. A researcher at a fraud-intelligence firm had messaged Solstice Commerce's abuse inbox with a screenshot: their checkout page was quietly POSTing card numbers to a domain in Eastern Europe. Not their code. A third-party chat widget script, loaded directly on the payment page, had been compromised weeks earlier and modified to skim every card Solstice's customers entered. Nobody on Maria's team had approved that script's presence on the payment page, nobody had an inventory of it, and nobody had noticed the change because nothing was watching for one.
By the time Solstice's incident responders, forensic investigators, and outside counsel finished totaling the damage — card brand fines, mandatory forensic investigation costs, breach notification, and six months of remediation — the number landed north of $2.3 million. The technical root cause fit in one sentence: nobody was managing the scripts running on the payment page, and nobody was watching for unauthorized changes to it. Both of those failures map directly to PCI DSS Requirement 6, and one of them — script management — is a control that didn't even exist in the standard until version 4.0.
Requirement 6 is the part of PCI DSS that governs how you build and maintain the software that touches cardholder data: your custom-written applications, the open-source and commercial components you bolt onto them, the patches you apply (or don't), the changes you push to production, and — since v4.0 — the third-party JavaScript running on your payment pages. It is consistently one of the most heavily cited requirements in Reports on Compliance, and it is the requirement where "we'll get to it" causes the most expensive incidents.
Who This Is For and What You'll Walk Away With
This guide is written for application security leads, DevSecOps engineers, QSAs preparing clients for assessment, and CISOs at merchants and service providers who process, store, or transmit cardholder data through applications they build or maintain. If your organization has a software development lifecycle, a public-facing web application, or an e-commerce payment page, Requirement 6 applies to you directly. You'll walk away with a control-by-control breakdown of Requirement 6's five sub-requirements, patch management SLAs mapped to CVSS severity, a working secure SDLC model, a side-by-side comparison of WAF versus manual review approaches, and a practical playbook for the new payment-page script inventory and change-detection controls that catch out nearly every e-commerce merchant on their first v4.0 assessment.
Requirement 6 in Plain English: What PCI DSS Actually Demands
PCI DSS v4.0 and v4.0.1 formally title Requirement 6 "Develop and Maintain Secure Systems and Software." It replaced the older, narrower v3.2.1 language ("Develop and maintain secure systems and applications") with a broader scope that explicitly captures modern software supply chains — third-party libraries, open-source components, low-code platforms, and the client-side scripts that run inside a customer's browser during checkout, not just the code your engineers write.
Requirement 6 breaks into five numbered sub-requirements, each built from a defined approach requirement (what you must do) paired with testing procedures (how a QSA or ISA verifies it) and, in most cases, a customized approach option (an alternative control that meets the same objective through a different mechanism, validated through a targeted risk analysis). The five sub-requirements are:
6.1 — Processes and mechanisms for developing and maintaining secure systems and software are defined and understood (the governance layer: policies, roles, and documented procedures).
6.2 — Bespoke and custom software is developed securely (secure coding training, secure SDLC, code review).
6.3 — Security vulnerabilities are identified and addressed (vulnerability identification, a software component inventory, and patch management).
6.4 — Public-facing web applications are protected against attacks (automated technical solutions or manual review, WAF deployment, and — new in v4.0 — payment page script management).
6.5 — Changes to all system components are managed securely (change control procedures, environment separation, duties separation, and live PAN handling in non-production environments).
That structure — governance, secure development, vulnerability management, application protection, change control — is the backbone of the rest of this article, and it's the same structure a QSA will use when they build your Requirement 6 testing plan.
Requirement 6 Sub-Requirements at a Glance
Sub-Requirement | Core Control | Primary Evidence a QSA Will Request | Who Typically Owns It |
|---|---|---|---|
6.1 | Documented Req 6 policies, roles, and annual review | Policy documents, review sign-off, org chart | CISO / AppSec Lead |
6.2 | Secure coding training + secure SDLC + code review | Training records, SDLC procedure docs, code review logs | Engineering Manager / AppSec |
6.3 | Vulnerability identification, software inventory, patching | Vuln scan/feed subscriptions, inventory, patch tickets | Vulnerability Management Lead |
6.4 | WAF or manual review of public-facing apps; script management | WAF config/logs or review reports, script inventory | AppSec / Web Ops |
6.5 | Change control, environment separation, no live PAN in test | Change tickets, environment diagrams, data sanitization logs | Change Manager / DevOps |
Why Requirement 6 Is the Requirement Most Teams Get Wrong
Requirement 6 sits at an awkward intersection: it's owned by engineering, but it's assessed by compliance, and the two groups rarely speak the same operational language. Engineering teams ship code continuously; compliance teams want quarterly evidence packages. Vulnerability management tools flag hundreds of findings; the standard demands you patch critical and high-severity ones within a fixed window regardless of how many there are. And the new payment-page script controls (6.4.3) ask e-commerce teams to inventory something — third-party JavaScript — that most of them have never formally tracked, because marketing, analytics, and support teams add tags and widgets to checkout pages without going through a change control process at all.
"The pattern I see across almost every Level 1 e-commerce merchant is the same: rock-solid change control for their own application code, and zero visibility into the six or seven third-party scripts marketing bolted onto the payment page over the last two years. Requirement 6.4.3 exists specifically because that blind spot has been exploited over and over again." — Derek Osei, QSA, Ashford Compliance Partners
The result is that Requirement 6 generates a disproportionate share of assessment findings relative to other requirements, particularly around 6.3.3 patch timelines, 6.4.1/6.4.2 web application protection evidence, and — since March 2025, when the previously future-dated v4.0 requirements became mandatory — 6.4.3 script inventory and authorization. If you're preparing for an assessment cycle in 2026, this is the requirement most likely to generate open items in your Report on Compliance if you haven't built the underlying processes yet.
6.2 — Building Bespoke and Custom Software Securely
Requirement 6.2 governs any software your organization develops in-house or has developed on its behalf — what PCI DSS calls bespoke and custom software, as distinct from commercial off-the-shelf products you purchase and configure. If your checkout flow, your payment API, your customer portal, or your internal tooling that touches cardholder data was written by your engineers or contractors, 6.2 applies.
6.2.1 — Secure Coding Training for Developers
Every developer who writes bespoke or custom software for in-scope systems must receive secure coding training at least once every twelve months, covering secure coding techniques relevant to the languages and frameworks they actually use, and including how to avoid common coding vulnerabilities. Generic "security awareness" training doesn't satisfy this control — the standard is explicit that the training must be role-specific to development work. Assessors want to see a training roster, course content mapped to the languages in use (a team writing Python and JavaScript shouldn't be handed a generic Java-focused course), and completion tracking.
6.2.2 — Secure Software Development Processes
Software must be developed based on industry standards and best practices, with information security built in throughout the software development lifecycle — not bolted on before release. Most organizations point to a secure SDLC model here, and increasingly reference frameworks like OWASP's Software Assurance Maturity Model or NIST's Secure Software Development Framework as their industry-standard baseline. Requirement 6.2.2 also expects developers to be following defined coding standards, and expects the organization to review those standards periodically.
6.2.3 — Code Review Before Release
Before bespoke or custom software is released to production, or moved from a pre-production environment, it must be reviewed for coding vulnerabilities — manually, or through an automated code review tool, or a combination of both. The reviewer must not be the same person who authored the code (a separation-of-duties principle that shows up again in 6.5.4), and reviews must confirm code was developed according to secure coding guidelines, addresses vulnerabilities before release, and that findings are remediated before release or the risk is formally accepted by management. A newer wrinkle in 6.2.3.1 (a v4.0 addition applying specifically to reviews of code that handles payment card data) reinforces the reviewer-independence requirement for that higher-risk code path.
6.2.4 — Addressing Common Software Attacks
Bespoke and custom software must be developed to prevent or mitigate common software attacks and vulnerabilities in accordance with an industry standard — PCI DSS names the OWASP Top 10, CWE/SANS Top 25, and similar lists as acceptable reference points, but doesn't mandate one specific framework. In practice this is where a target QSA will ask you to walk through exactly how your secure coding standard addresses injection flaws, broken authentication, sensitive data exposure, broken access control, security misconfiguration, and the rest of the categories your chosen standard covers.
"6.2.4 trips people up because they think 'we use a WAF, so we're covered.' A web application firewall is a compensating layer, not a substitute for writing code that doesn't have the vulnerability in the first place. Assessors want to see the vulnerability class addressed in your secure coding standard and your review checklist, independent of whatever runtime protection you've deployed." — Priya Nair, AppSec Lead, NorthPeak Payments
OWASP Top 10 Categories Mapped to PCI DSS 6.2.4 Coverage
OWASP Category (2021 Edition) | What It Covers | Primary Req 6 Control That Should Address It |
|---|---|---|
A01 Broken Access Control | Users acting outside intended permissions | 6.2.4 coding standard + 7.x access control |
A02 Cryptographic Failures | Weak/missing encryption of sensitive data | 6.2.4 + Requirement 3 & 4 crypto controls |
A03 Injection | SQL, command, LDAP injection via untrusted input | 6.2.4 input validation standard |
A04 Insecure Design | Missing security controls at the design stage | 6.2.2 secure SDLC, threat modeling |
A05 Security Misconfiguration | Default settings, verbose errors, open cloud storage | 6.2.4 + Requirement 2 configuration standards |
A06 Vulnerable and Outdated Components | Unpatched libraries and frameworks | 6.3.2 inventory + 6.3.3 patching |
A07 Identification and Authentication Failures | Weak session/credential handling | 6.2.4 + Requirement 8 authentication |
A08 Software and Data Integrity Failures | Unsigned updates, insecure deserialization, unmanaged scripts | 6.2.4 + 6.4.3 script management |
A09 Security Logging and Monitoring Failures | Insufficient detection of exploitation | 6.2.4 + Requirement 10 logging |
A10 Server-Side Request Forgery | Server tricked into making unintended requests | 6.2.4 input validation standard |
Secure SDLC Stages and Required Req 6 Controls
SDLC Stage | Activity | Req 6 Control | Typical Evidence |
|---|---|---|---|
Requirements | Define security/compliance requirements alongside functional ones | 6.2.2 | User stories with security acceptance criteria |
Design | Threat modeling, secure architecture review | 6.2.2 | Threat model document, architecture sign-off |
Development | Secure coding to documented standard | 6.2.1, 6.2.4 | Coding standard doc, training records |
Code review | Independent review before merge/release | 6.2.3 | Pull request approvals, SAST scan results |
Testing | SAST/DAST, dependency scanning | 6.3.1, 6.3.2 | Scan reports, vulnerability tickets |
Pre-production | Separation from production, sanitized data | 6.5.3, 6.5.5 | Environment inventory, data masking logs |
Release | Change control approval, rollback plan | 6.5.1, 6.5.2 | Change tickets, CAB approval records |
Post-release | Patch monitoring, vulnerability re-scan | 6.3.3 | Patch SLA tracker, re-scan evidence |
Secure SDLC and Patch Management Flow
The diagram below shows how the secure SDLC controls in 6.2 feed into the vulnerability identification and patch management controls in 6.3, and how a change re-enters the cycle through 6.5's change control gate.
flowchart TD
A[Requirements & Threat Modeling] --> B[Secure Coding - 6.2.1 / 6.2.4]
B --> C[Independent Code Review - 6.2.3]
C --> D{Vulnerabilities Found?}
D -- Yes --> B
D -- No --> E[Change Control Approval - 6.5.1 / 6.5.2]
E --> F[Deploy to Production]
F --> G[Continuous Vulnerability Identification - 6.3.1]
G --> H{Severity per CVSS / Risk Rank}
H -- Critical/High --> I[Patch within 30 Days - 6.3.3]
H -- Medium/Low --> J[Patch per Risk-Ranked Timeline]
I --> K[Update Software Inventory - 6.3.2]
J --> K
K --> G
F --> L[Public-Facing App Protection - 6.4.1 / 6.4.2]
F --> M[Payment Page Script Inventory - 6.4.3]
M --> N[Change & Tamper Detection - 11.6.1]6.3 — Identifying and Managing Vulnerabilities
Where 6.2 is about writing code well, 6.3 is about assuming you'll still ship vulnerabilities anyway — because everyone does — and building the process to find and fix them before an attacker does.
6.3.1 — Vulnerability Identification Process
Organizations must identify security vulnerabilities using reputable outside sources for vulnerability information, assign a risk ranking to newly discovered vulnerabilities (using industry-recognized practices such as CVSS scores, or the vendor's own severity rating), and cover both bespoke/custom software and third-party components. In practice, this means subscribing to vendor security advisories, the CISA KEV catalog, and vulnerability databases, then feeding what you find into a risk-ranking process rather than a single "patch everything eventually" queue. Vulnerabilities that are actively being exploited in the wild (the CISA KEV catalog specifically tracks these) should generally get pulled to the front of the queue regardless of their raw CVSS score.
6.3.2 — Maintaining a Software Component Inventory
This is the control most organizations underestimate. PCI DSS v4.0 requires an inventory of bespoke and custom software, and third-party software components incorporated into bespoke and custom software, to facilitate vulnerability and patch management. In modern terms, this is a software bill of materials (SBOM) requirement — you need to know, at minimum, which open-source libraries, frameworks, and commercial components are embedded in every in-scope application, and at what version, so that when a new CVE drops for a library, you can answer "are we exposed?" in minutes rather than weeks of manual code archaeology.
"Before we built our component inventory, a critical Log4j-class vulnerability meant two weeks of every engineer grepping through repos trying to figure out if we used the library anywhere. Now it's a five-minute query. That inventory paid for itself the first time we needed it." — Sofia Alvarez, DevSecOps Manager, Cobalt Fintech
Building a Software Component Inventory — What to Track
Field | Why It Matters | Update Trigger |
|---|---|---|
Component name and version | Matches against CVE/vendor advisories | New dependency added |
Source (vendor, open-source repo) | Determines advisory feed to monitor | New dependency added |
Application(s) using it | Scopes impact when a vuln is disclosed | Dependency added/removed |
License type | Legal/operational risk, not just security | Dependency added |
Last updated / patch level | Drives 6.3.3 SLA tracking | Every patch cycle |
Owning team | Accountability for remediation | Team reassignment |
End-of-life / support status | Flags components needing replacement | Vendor EOL announcement |
6.3.3 — Patch Management: Critical and High Within One Month
This is the sub-requirement with the hardest, most auditable deadline in all of Requirement 6: security patches and updates for critical and high-severity vulnerabilities must be installed within one month of release. Other, lower-risk patches must be installed within a timeframe defined by the organization's own risk analysis — but critical and high doesn't get a risk-based extension; it gets thirty days, full stop, unless a documented compensating control or customized-approach justification is in place.
"The thirty-day clock for critical and high vulnerabilities is non-negotiable in the way most of Requirement 6 isn't. I've had clients try to argue a targeted risk analysis around it, and it's a much higher bar than most people expect — you need to demonstrate an equivalent level of protection, not just a business reason why patching was inconvenient that month." — Tom Whitfield, CISO, Meridian Retail Group
Patch Management SLAs by Severity
Severity | Typical CVSS Range | Required Timeline (6.3.3) | Common Compensating Control If Delayed |
|---|---|---|---|
Critical | 9.0–10.0 | Within 1 month of patch release | Virtual patching via WAF rule, network isolation |
High | 7.0–8.9 | Within 1 month of patch release | Enhanced monitoring, access restriction |
Medium | 4.0–6.9 | Per organization's documented risk-based timeline | Scheduled maintenance window |
Low | 0.1–3.9 | Per organization's documented risk-based timeline | Next regular patch cycle |
Actively exploited (any score) | Any | Treat as critical regardless of base score | Emergency change process |
6.4 — Protecting Public-Facing Web Applications
Requirement 6.4 addresses the applications your customers interact with directly over the internet — the ones with the largest attack surface and the least forgiving audience if something goes wrong.
6.4.1 and 6.4.2 — Automated Protection or Regular Manual Review
Public-facing web applications must be protected against attacks through one of two defined-approach paths. Under 6.4.1, organizations can rely on manual or automated application vulnerability security assessment tools or methods, reviewing applications at least once every twelve months and after significant changes, with a process to address vulnerabilities found. Under 6.4.2 — which became mandatory alongside the rest of the future-dated v4.0 requirements — organizations handling this at scale are expected to deploy an automated technical solution, commonly a web application firewall, that continually detects and prevents web-based attacks, runs actively (not just in monitoring/logging mode), generates audit logs, and is configured to either block attacks or generate an alert that is immediately investigated.
The two paths aren't strictly either/or in every reading of the standard — many organizations run both a WAF for continuous protection and periodic manual/automated assessments for depth a WAF's signature-based detection won't catch, such as business logic flaws. But if you're only doing annual reviews with no continuous automated protection layer, you're relying entirely on 6.4.1 and need to be able to show the review cadence and remediation process hold up on their own.
Web Application Protection Options Compared
Approach | Mechanism | Detection Depth | Ongoing Effort | Best Fit |
|---|---|---|---|---|
Web application firewall (WAF) | Inline traffic inspection, rule/ML-based blocking | Strong on known attack patterns (injection, XSS) | Moderate — tuning, rule updates | High-traffic public apps, continuous coverage |
Manual code/application review | Human-led assessment, often paired with penetration testing | Strong on business logic flaws WAFs miss | High — skilled reviewer time | Complex apps, lower change frequency |
Automated DAST scanning | Scripted attack simulation against running app | Moderate — good breadth, weaker on logic flaws | Low-moderate — scheduled scans | Supplementing WAF or manual review |
Runtime application self-protection (RASP) | In-app monitoring/blocking at the code level | Strong, application-context aware | Moderate — integration effort | Apps needing protection independent of network path |
6.4.3 — The New Rule: Managing Payment Page Scripts
Requirement 6.4.3 is the control most directly responsible for closing the gap that hurt Solstice Commerce. It applies to payment pages delivered to a consumer's browser and requires that all payment page scripts loaded and executed in that browser be managed as follows: a method is implemented to confirm that each script is authorized, a method is implemented to assure the integrity of each script, and an inventory of all scripts is maintained with written business or technical justification for why each one is necessary.
The control exists because of exactly the attack pattern behind Magecart-style card-skimming campaigns: an attacker compromises a third-party script vendor (a chat widget, an analytics tag, an A/B testing tool, an ad pixel — anything loaded client-side on the checkout page), modifies the script to silently capture and exfiltrate card data as the customer types it, and because nobody was tracking which scripts belonged on the page or whether they'd changed, the compromise runs undetected for weeks or months. 6.4.3 forces organizations to know exactly what's running on the payment page and to have a mechanism — subresource integrity hashes, a script inventory tied to a change approval process, a script-management platform, or an equivalent customized-approach control — that would catch an unauthorized addition or modification.
"6.4.3 was the wake-up call for our marketing and martech teams. They'd been adding tags to the checkout page for years through a completely separate process from engineering's change control. Building the inventory meant, for the first time, engineering and marketing sitting in the same room agreeing on what's actually allowed to load on that page." — James Okoro, Director of PCI Compliance, LatticePay
Payment Page Script Inventory — Required Fields
Field | Purpose | Example |
|---|---|---|
Script name/identifier | Uniquely identify the script | "LiveChat widget v4.2" |
Source/origin (domain) | Confirm expected hosting location | chat-vendor.example.com |
Business/technical justification | Document why it's necessary (required by 6.4.3) | "Customer support chat during checkout" |
Authorization owner | Who approved it running on the payment page | AppSec Lead |
Integrity verification method | How you confirm it hasn't been tampered with | Subresource Integrity (SRI) hash |
Date added / last reviewed | Supports periodic re-validation | Reviewed quarterly |
Removal/deprecation date | Tracks scripts retired from the page | If applicable |
6.4.3 vs. 11.6.1 — How the Two New Payment-Page Controls Work Together
PCI DSS pairs the script inventory control in 6.4.3 with a detection control in Requirement 11: 11.6.1 requires a change- and tamper-detection mechanism that alerts personnel to unauthorized modification of HTTP headers and the content of payment pages as received by the consumer's browser, evaluated at least weekly (or more frequently if defined by a targeted risk analysis). Where 6.4.3 answers "what's allowed to be on this page and who authorized it," 11.6.1 answers "has anything on this page actually changed since we last checked." Together they form a preventive-plus-detective control pair specifically engineered to stop the skimming pattern that has driven a disproportionate share of e-commerce card-data breaches since Magecart-style attacks became widespread. A detailed walkthrough of the detection side of that pairing belongs to Requirement 11 (security testing) rather than this article, but no Requirement 6 program is complete without confirming the two controls are actually linked operationally — the inventory has to feed the detection tool's baseline, or the detection tool has nothing to compare against.
Dimension | 6.4.3 (Requirement 6) | 11.6.1 (Requirement 11) |
|---|---|---|
Control type | Preventive / authorization | Detective / monitoring |
What it governs | Which scripts are allowed on the payment page | Whether the page's actual content/headers have changed |
Core mechanism | Inventory + authorization + integrity method | Automated change- and tamper-detection tool |
Minimum frequency | Ongoing management, periodic review | At least weekly evaluation |
Failure mode it closes | Unauthorized/unknown script added to page | Authorized script silently modified in place |
6.5 — Managing Changes Securely (Change Control)
Requirement 6.5 is where Requirement 6 meets the broader discipline of change management — the same control family that shows up under different names in nearly every framework, including ISO 27001 and SOC 2. It governs how changes to any system component (not just applications) move from development through to production without introducing new risk.
The Six 6.5 Sub-Controls
6.5.1 — Documented change control procedures covering description of change, documented reason, impact assessment, approval by authorized parties, functionality testing, and back-out procedures.
6.5.2 — Upon completion of a significant change, confirmation that all applicable PCI DSS requirements are still met and documentation is updated as needed.
6.5.3 — Pre-production environments are separated from production environments, with access control enforced between them.
6.5.4 — Separation of duties between personnel assigned to development/test roles and personnel assigned to production roles.
6.5.5 — Live production PANs are not used in pre-production (development/test) environments, except where those environments meet the same security controls as production.
6.5.6 — Test data and test accounts are removed from system components before the system becomes active or goes into production.
Change Control Sub-Requirements
Control | Requirement | Common Evidence | Common Failure Point |
|---|---|---|---|
6.5.1 | Documented, approved change procedure | Change tickets with impact assessment and back-out plan | Emergency changes bypass the process entirely |
6.5.2 | Confirm PCI DSS requirements still met post-change | Post-change compliance checklist sign-off | Skipped for "minor" changes that turn out significant |
6.5.3 | Pre-production/production separation | Network/environment diagrams, access lists | Shared credentials or flat network between environments |
6.5.4 | Duties separated: dev/test vs. production | Access control matrix, role definitions | Same engineer has deploy rights to both environments |
6.5.5 | No live PAN in dev/test | Data masking/tokenization logs, code scan of test DBs | Production database copied "temporarily" for debugging |
6.5.6 | Test data/accounts removed before go-live | Pre-release checklist, decommission logs | Default/test admin accounts left active in production |
"6.5.5 is the one that gets people in the most trouble during forensic investigations, not assessments. A breach investigator loves nothing more than finding a full copy of the production cardholder database sitting in a staging environment with weaker controls than production — and it happens constantly, because 'just for this one debugging session' becomes permanent." — Maria Chen, VP Engineering, Solstice Commerce
Development/Test vs. Production Separation Checklist
Control Area | Development/Test Requirement | Production Requirement |
|---|---|---|
Network access | Logically or physically segmented from production | Isolated per Requirement 1 network controls |
User accounts | Separate credentials from production accounts | No shared accounts with dev/test |
Cardholder data | Tokenized, masked, or synthetic — never live PAN | Live data protected per Requirement 3 |
Deployment rights | Developers may have deploy access | Restricted to release/ops roles (6.5.4) |
Logging | Reviewed but lower retention typically acceptable | Full Requirement 10 logging retained |
Test accounts/data | Present during testing | Removed before go-live (6.5.6) |
Case Study: Solstice Commerce and the Payment-Page Skimmer
Solstice Commerce, a mid-market e-commerce retailer processing roughly 40,000 card transactions a month, had passed three consecutive PCI DSS assessments under v3.2.1 without a single Requirement 6 finding. Their internally developed checkout application had solid secure coding practices, mature code review, and a disciplined change control process — all genuinely well run. What they didn't have, because it wasn't yet a formal requirement, was any inventory of the third-party scripts marketing and customer-support teams had added directly to the payment page over four years: a live chat widget, two analytics pixels, an A/B testing tool, and a retargeting tag.
When the chat vendor's script-hosting infrastructure was compromised, the injected skimming code sat on Solstice's live payment page for approximately seven weeks before an external fraud researcher spotted the anomalous outbound POST request and reported it. The forensic investigation, mandatory under the card brands' incident response programs, confirmed skimmed data from an estimated 6,100 transactions. Total cost — forensic investigation fees, card brand fines, replacement card costs passed through by issuers, legal fees, and the six-figure marketing spend on customer trust recovery — reached $2.3 million.
Solstice's remediation, completed over four months, became a template later used across their SAQ-D peer group: a formal script inventory built jointly by engineering, marketing, and compliance; an authorization workflow requiring AppSec sign-off before any script could be added to the payment page; subresource integrity hashing on every retained script; and a weekly automated change- and tamper-detection scan of the live payment page. Post-remediation, Solstice's next assessment cycle recorded zero Requirement 6 findings, and their time-to-detect for an unauthorized page change dropped from seven weeks to under four hours.
Case Study: NorthPeak Payments' Secure SDLC Turnaround
NorthPeak Payments, a Level 1 service provider processing card-not-present transactions for mid-sized merchants, entered a QSA readiness assessment with a Requirement 6 problem that had nothing to do with scripts: their patch management program had no formal SLA, critical vulnerabilities routinely sat unpatched for 60–90 days, and their code review process was inconsistently applied across three engineering teams that had grown through two acquisitions with different development cultures.
Priya Nair's AppSec team spent the first sixty days building a unified software component inventory across all three codebases, discovering in the process that one acquired product was running a web framework version with two unpatched critical CVEs. The team implemented a hard 30-day SLA for critical and high findings, backed by an automated dependency-scanning pipeline that opened a ticket the same day a new CVE was published against any tracked component, and standardized code review requirements — including mandatory reviewer independence — across all three teams.
Within two assessment cycles, NorthPeak's mean time to patch critical vulnerabilities dropped from 74 days to 19 days, comfortably inside the 30-day requirement, and their QSA's testing sample of code review records showed 100% reviewer-independence compliance, up from an inconsistent 60–70% across the three legacy teams. Their Report on Compliance moved from four open Requirement 6 items to zero.
Evidence Auditors Expect for Requirement 6
Control Area | Evidence a QSA/ISA Will Request | How Far Back |
|---|---|---|
6.1 Governance | Signed, current Req 6 policy; annual review record | Current version + prior annual review |
6.2 Secure development | Training completion logs, coding standard, code review logs | Full assessment period |
6.3 Vulnerability management | Vulnerability feed subscriptions, risk-ranking methodology, patch tickets | Full assessment period, sampled |
6.3.3 Patch SLA | Ticket timestamps from disclosure to patch deployment | Full assessment period, sampled |
6.4 Web app protection | WAF configuration/logs, or manual review reports and remediation tickets | Rolling 12 months |
6.4.3 Script management | Script inventory, authorization records, integrity verification logs | Current + change history |
6.5 Change control | Change tickets with impact assessment, approvals, back-out plans | Full assessment period, sampled |
6.5.5/6.5.6 | Data masking evidence, test account decommission logs | Full assessment period, sampled |
Roles and Responsibilities for Requirement 6
Activity | Responsible | Accountable | Consulted | Informed |
|---|---|---|---|---|
Secure coding standard maintenance | AppSec Lead | CISO | Engineering Managers | Development teams |
Developer secure coding training | Engineering Managers | CISO | AppSec Lead | HR/L&D |
Code review enforcement | Tech Leads | Engineering Director | AppSec Lead | QA |
Software component inventory | DevSecOps | AppSec Lead | Development teams | Vulnerability Management |
Patch SLA tracking | Vulnerability Management Lead | CISO | Engineering Managers | Executive leadership |
Payment page script authorization | AppSec Lead | CISO | Marketing/Martech, Legal | QSA/ISA |
Change control approval | Change Advisory Board | Head of Engineering | Security, Compliance | All stakeholders |
Common Requirement 6 Failures and How to Fix Them
Failure Pattern | Why It Happens | Fix |
|---|---|---|
No formal patch SLA tracking | Vulnerabilities tracked informally in tickets, no severity-based deadline | Automated pipeline that timestamps disclosure-to-patch against 30-day rule |
Code review without reviewer independence | Small teams, deadline pressure, self-approval | Mandatory second reviewer, enforced via merge/branch protection rules |
No software component inventory | Dependencies managed per-project, never aggregated | Centralized SBOM tooling integrated into build pipeline |
Payment page scripts added outside engineering process | Marketing/martech tags added via tag manager, bypassing change control | Joint script authorization workflow spanning engineering, marketing, security |
Production data copied into test environments | "Just for debugging," never cleaned up | Automated data masking/tokenization for all non-production copies |
WAF deployed but not actively blocking | Left in monitoring-only mode after initial rollout | Periodic WAF rule review; require active blocking per 6.4.2 |
Change control skipped for "emergency" fixes | No defined emergency change path, so people bypass the process | Documented expedited-approval path that still requires post-hoc review |
Illustrative Cost of a Requirement 6 Program by Organization Size
Organization Profile | Secure SDLC Tooling (Annual) | WAF/Script Management (Annual) | Internal Staffing Estimate | Notes |
|---|---|---|---|---|
Small e-commerce merchant (SAQ A-EP/B-IP scope) | $8,000–$20,000 | $6,000–$15,000 | 0.25–0.5 FTE | Often outsources code review to a contracted assessor |
Mid-market merchant/service provider | $30,000–$80,000 | $20,000–$50,000 | 1–2 FTE | Dedicated AppSec function typically emerges here |
Level 1 service provider | $100,000–$300,000+ | $60,000–$150,000+ | 3–6 FTE | Full secure SDLC tooling chain, dedicated script management platform |
These figures are illustrative planning ranges based on typical engagements, not vendor quotes — actual costs vary by tooling choices, existing infrastructure, and whether functions are outsourced.
Which SAQ Types Touch Requirement 6
Not every merchant validates against the full Requirement 6 control set — it depends heavily on your Self-Assessment Questionnaire type, which in turn depends on how you handle card data.
SAQ Type | Requirement 6 Applicability | Why |
|---|---|---|
SAQ A | Minimal — no Req 6 questions in most versions | Fully outsourced payment processing, no card data touches merchant systems |
SAQ A-EP | Significant — includes 6.4.3 script controls | Merchant's page influences the payment iframe/redirect even without directly handling PAN |
SAQ B / B-IP | Minimal | Standalone terminals, no e-commerce web application |
SAQ C | Moderate | Payment application on merchant-managed system, segmented network |
SAQ D (Merchant) | Full Requirement 6 | Merchant directly processes/stores/transmits card data through custom systems |
SAQ D (Service Provider) | Full Requirement 6, often plus ROC-level testing | Broadest scope, typically Level 1 with QSA-led assessment |
Requirement 6 vs. Requirement 5 vs. Requirement 11 — How They Relate
Requirement 6 doesn't operate in isolation — it's the middle layer of PCI DSS's vulnerability management goal, and it hands off directly to the testing requirements in Requirement 11. Understanding the boundary matters, because assessors will ask you to show where one control's evidence ends and the next begins. Our companion guide on malware protection under Requirement 5 covers the anti-malware side of the same "Maintain a Vulnerability Management Program" goal that Requirement 6 anchors.
Requirement | Focus | Relationship to Requirement 6 |
|---|---|---|
Requirement 5 | Anti-malware protection across all systems | Runtime defense; Req 6 prevents vulnerabilities malware would exploit |
Requirement 6 | Secure development, patching, change control, web-app/script protection | The build-and-maintain layer covered in this article |
Requirement 11 | Regular security testing — scanning, penetration testing, tamper detection (11.6.1) | Validates that Req 6 controls actually held; 11.6.1 detects what 6.4.3 was meant to prevent |
Building Your Requirement 6 Program: A 90-Day Roadmap
Most organizations building a Requirement 6 program from a standing start — or retrofitting one to close v4.0 gaps — follow a recognizable sequence. Week one starts with an inventory exercise, not a policy-writing exercise, because you can't govern what you can't see: catalog every bespoke and custom application in scope, every third-party component inside them, and every script running on public payment pages. That inventory becomes the spine everything else attaches to.
From there, the sequence typically moves to formalizing the patch SLA (because it has the hardest deadline and the clearest audit trail), then to code review independence and secure coding training (because they're process changes that take longest to embed into team habits), then to WAF deployment or manual review scheduling, and finally to the payment-page script authorization workflow, which — as both case studies above show — usually requires the most cross-functional negotiation because it's the one control area engineering doesn't fully own.
90-Day Requirement 6 Implementation Roadmap
Phase | Timeframe | Key Activities | Milestone |
|---|---|---|---|
Discovery | Days 1–15 | Inventory bespoke apps, components, and payment page scripts | Complete asset/script inventory |
Governance | Days 16–30 | Draft/update Req 6 policy, assign RACI ownership | Policy approved by CISO |
Vulnerability & Patch | Days 31–50 | Stand up risk-ranking process, enforce 30-day SLA | First full patch cycle within SLA |
Secure Development | Days 51–65 | Deliver secure coding training, formalize reviewer independence | Training completion, review policy live |
Web/App Protection | Days 66–80 | Deploy/tune WAF or schedule manual review cadence | Active blocking confirmed |
Script & Change Control | Days 81–90 | Launch script authorization workflow, tie to 11.6.1 detection | Script inventory + detection tool linked |
Requirement 6 as a Business Opportunity, Not Just a Checkbox
It's tempting to treat Requirement 6 as pure overhead — training hours, review gates, patch SLAs that slow down shipping velocity. The organizations that get the most value out of it treat it differently: a secure SDLC with enforced code review and dependency tracking is also, not coincidentally, the foundation of a mature engineering organization that ships fewer production incidents overall, not just fewer security ones. A software component inventory built for PCI DSS is the same inventory your engineering leadership needs to plan framework upgrades and estimate technical debt. And a payment-page script authorization process, once built, becomes a selling point — the kind of operational maturity that shortens due-diligence cycles when a large retail partner or payment processor is evaluating whether to route volume through you.
Solstice Commerce's post-incident script management program didn't just close a compliance gap — it became a reference architecture the company now points to in enterprise sales conversations with prospective marketplace partners who ask pointed questions about payment-page security before signing. Requirement 6 done well is a demonstrable trust signal in a market where card-not-present fraud and e-commerce skimming attacks remain a constant background risk for every buyer's own compliance team to worry about.
If you're building or maturing your Requirement 6 program, PentesterWorld's PCI DSS 12-Requirements Checklist gives you a control-by-control starting point, and the PCI DSS Policy Pack includes editable templates for the secure development, patch management, and change control policies this article covers. If you're not yet sure how far along your organization is, our PCI DSS Gap Analysis Tool will help you baseline before you invest in tooling, and the full PCI DSS Glossary is a handy reference for the terminology across all twelve requirements.
For the full picture of how Requirement 6 fits into the standard end to end, start with our PCI DSS Complete Guide, and pair this article with PCI DSS Requirement 5's anti-malware controls to cover the full vulnerability management goal. Organizations running both PCI DSS and ISO 27001 will find natural overlap with the secure development lifecycle controls in ISO 27001 Annex A 8.25–8.29, and teams reconciling change control expectations across frameworks should also read our SOC 2 coverage of change management for system updates — the underlying discipline of documented, approved, tested change is the same control wearing three different framework labels.