When an organization starts accepting card payments, one quiet but powerful shift happens in the background: it becomes part of the global payment security ecosystem. That ecosystem is governed by the Payment Card Industry Data Security Standard (PCI DSS), a framework designed to protect cardholder data from theft and misuse.
One of the most impactful parts of that framework is Requirement 6, which focuses on how you develop and maintain secure systems and software. If your business builds, buys, or configures any IT systems, Requirement 6 touches you directly.
In this article, I will walk you through Requirement 6 step by step. I will break down what the requirement expects, why it matters in real environments, and how you can implement it in a way that supports both security and business goals.
PCI DSS requirement 6 overview: Develop and maintain secure systems and software
Requirement 6 can be summarized as a demand that you systematically manage vulnerabilities and develop software securely. It connects three domains that are often treated separately: vulnerability management, patch management, and secure software development. The requirement is not just about having tools; it is about having documented processes, defined responsibilities, and evidence that activities occur consistently.
The core idea is straightforward. You must identify vulnerabilities in your systems and applications, evaluate the risk they pose, prioritize remediation, and ensure that changes are applied in a controlled way.
At the same time, any software you develop or customize must follow secure design and coding practices, be tested for security issues, and be maintained throughout its lifecycle. If you treat Requirement 6 as a checklist, you will struggle. If you treat it as a security lifecycle, it becomes much more manageable.
PRO TIP
Before you jump into tools or policies, map where cardholder data flows within your environment and which systems or applications touch it. Once you know which components are in scope, you can apply Requirement 6 precisely, instead of trying to boil the ocean across your entire IT landscape.
Vulnerability management: Identifying and prioritizing weaknesses
A key part of Requirement 6 is having a structured process to identify security vulnerabilities that could affect your systems and applications. This usually means monitoring vendor advisories, threat intelligence, and vulnerability feeds, and combining them with regular internal and external vulnerability scans. The goal is not just to collect information, but to translate it into action.
You are expected to classify vulnerabilities based on risk, which typically means looking at severity scores, exploit availability, and how exposed the affected system is.
A critical vulnerability on an internet-facing web server that handles card payments is not the same as a medium-severity issue on an internal test server. Your process must reflect that distinction. Documenting this triage logic is as important as running the scans themselves, because auditors will ask how you decide what to fix first.
Patch management: Timely remediation of discovered vulnerabilities
Requirement 6 also expects you to apply vendor-supplied security patches in a timely manner. This does not mean installing every patch the moment it is released, but it does mean having clear timelines based on risk and ensuring that security patches are handled with priority. In many environments, this is where friction surfaces between operations and security teams, especially when patches can potentially disrupt critical services.
To satisfy both PCI DSS and practical reliability concerns, you need a structured patch management process. That process should describe how patches are evaluated, tested in non-production environments, scheduled for deployment, and verified after installation.
It should also define who has the authority to approve emergency changes when a critical vulnerability needs expedited treatment. Evidence of patch cycles, test results, and change approvals becomes essential during audits.
PRO TIP
Rather than treating patching as a separate activity, embed it into your existing change management process. Create patch “windows” that are known across the business, and use standard change records to document planning, testing, rollback steps, and approvals. This reduces resistance and makes your evidence set much stronger.
Secure software development: Building security into the lifecycle
If your organization develops or customizes software that touches cardholder data, Requirement 6 expects you to apply secure software development practices across the full lifecycle. This aligns well with secure SDLC (Secure Software Development Life Cycle) concepts that many organizations already use. The key point is that security cannot be an afterthought or something only tested at the end.
You should define and document secure coding standards based on common vulnerabilities such as those listed in the OWASP Top 10 (for example, injection flaws, broken authentication, and insecure direct object references).
Developers must be trained to understand these issues and how to avoid them. In addition, your development process should include security-focused activities such as threat modeling, static code analysis, and security testing before applications are promoted to production.
Code review and testing: Verifying that security controls work
Requirement 6 also emphasizes independent review and testing of code changes. This means that changes should be reviewed by someone other than the original developer, with specific attention to security implications. The review is not just a stylistic check; it is a structured examination for potential vulnerabilities. Pair programming, pull requests with mandatory reviewers, and defined review checklists all help meet this expectation.
Beyond human review, technical testing is important. Static Application Security Testing (SAST) tools can evaluate code for known patterns of insecure behavior, while Dynamic Application Security Testing (DAST) tools can probe running applications for exploitable issues.
Penetration testing can complement these by simulating attacker techniques. Evidence of these activities, including findings and remediation actions, shows that you are not just writing policies but actually validating your software’s resilience.
PRO TIP
Provide reviewers with a concise security checklist that covers topics such as input validation, authentication, authorization, logging, and error handling. This shifts reviews from ad hoc opinions to repeatable checks and makes it easier to train new reviewers.
Change control: Managing the risk of modification
Another core piece of Requirement 6 is change control. Any change to systems in scope for PCI DSS—whether it is a configuration change, a patch, or a code deployment—must follow a documented process. The purpose is to ensure that changes are introduced in a controlled way, with risk assessment, testing, approvals, and rollback plans where appropriate.
In practice, a robust change control process means that each change has a clear description, a reason, an impact analysis, a test plan, and evidence that it was tested. It also requires that the person who approves the change is not the same person who implements it, to preserve separation of duties.
When implemented well, change control protects payment systems from accidental misconfigurations and rushed deployments that can open security holes.
Web application security: Protecting public-facing interfaces
Public-facing web applications that handle or access cardholder data are high-value targets for attackers. Requirement 6, therefore, expects you to protect them through a combination of secure development practices and additional controls such as web application firewalls (WAFs) or equivalent technical measures. The intent is to ensure that even if an application has a residual vulnerability, there is another layer of defense in place.
Your strategy here should combine prevention and detection. Prevention includes secure coding, regular application security testing, and timely patching. Detection and protection include using a WAF to block common attack patterns, logging suspicious requests, and alerting your security operations team to investigate. When these layers work together, the likelihood of a successful attack through your payment web application is significantly reduced.
PRO TIP
Avoid leaving your WAF in a generic “default” mode. Monitor actual traffic, analyze false positives and real attack attempts, and tune the rules accordingly. This reduces noise for your security team and ensures that the WAF is genuinely aligned with your application rather than simply generating logs.
Documentation and evidence: Turning practice into compliance
No matter how strong your technical practices are, PCI DSS compliance requires that you can demonstrate them. Requirement 6, therefore, implicitly depends on solid documentation and record keeping. This includes policies and procedures, training records, change tickets, vulnerability scan reports, patch logs, and test evidence from your SDLC.
The most efficient organizations do not create documents only for audits. They integrate documentation into their daily workflows so evidence is generated automatically. For example, ticketing systems can record change approvals, code repositories can store review comments, and vulnerability management platforms can export remediation reports. When an assessment arrives, you are not scrambling to reconstruct what happened; you are simply presenting records that reflect normal operations
Moving from checklist to continuous security
PCI DSS Requirement 6 is often perceived as a collection of tasks: patch this, scan that, write a policy. In reality, it is a blueprint for building a continuous security lifecycle around your systems and software. When you treat it as an opportunity to formalize vulnerability management, secure development, and change control, you strengthen your resilience far beyond what the standard strictly demands.
If you focus on clear processes, risk-based prioritization, and integrated evidence, compliance becomes a natural outcome of how you operate instead of an annual fire drill. Your next step is to review how your organization currently identifies vulnerabilities, manages patches, develops software, and controls changes. Then, align those activities explicitly with Requirement 6 so that every security improvement you make also supports your PCI DSS obligations.
Choose Copla for PCI DSS — and stop running PCI on spreadsheets
PCI DSS is the price of accepting cards. Copla makes hitting v4.0.1 — including the March 2025 changes — faster, cheaper, and radically less painful.
Why teams choose Copla:
- Shrink your CDE, shrink your PCI bill: Scope-minimization playbooks (tokenization, hosted payments, segmentation) cut effort and assessor questions.
- v4.0.1 done-for-you: Pre-mapped controls, policies, and workflows for all 12 requirements — including TRAs, MFA, and logging/retention.
- Evidence on autopilot: Automate access reviews, training, vendor AoCs, scan/pen-test tracking, and export-ready SAQ/RoC packages.
Typical outcome: 40–70% faster readiness and 40–70% lower internal PCI cost. PCI is non-negotiable. Doing it the hard way is.
The only PCI DSS compliance management platform you’ll need
Copla brings together PCI-native capabilities, from CDE asset and risk registers, v4.0.1 control and evidence mapping, to vulnerability management and awareness training — all in one place.
