PCI DSS 6.2.1: Bespoke and custom software are developed securely
PCI DSS v4.0.1 control 6.2.1: the requirement in full, the 1 testing procedure an assessor uses to verify it, and the related controls in section 6.2.
Requirement 6: Develop and Maintain Secure Systems and Software › Section 6.2
Bespoke and custom software are developed securely, as follows:
- Based on industry standards and/or best practices for secure development.
- In accordance with PCI DSS (for example, secure authentication and logging).
- Incorporating consideration of information security issues during each stage of the software development lifecycle.
Summary
Have a documented way of building software securely: based on a recognised standard, meeting PCI DSS in the code itself, and considering security at every stage rather than at the end.
What the assessor will examine
These are the testing procedures the standard defines for this control. They tell you what evidence to have ready.
| Procedure | |
|---|---|
| 6.2.1 | Examine documented software development procedures to verify that processes are defined that include all elements specified in this requirement. |
The umbrella that the rest of 6.2 implements: 6.2.2 trains the developers, 6.2.3 reviews what they write, 6.2.4 names the techniques. The second bullet is the one that surprises people. "In accordance with PCI DSS" means the software you write must itself implement the standard's controls, and the examples given are secure authentication and logging. Requirements 8 and 10 apply to your own application, not only to the platforms you bought. The third bullet says "each stage", which rules out a single security gate before release. The only procedure examines documented procedures, so this control is won or lost on whether the process is written down.
What to prepare
- The secure development procedures themselves, naming the standard or practices they are based on.
- The mapping from your SDLC stages to the security activity in each: requirements, design, build, test, release.
- Evidence that the software implements PCI DSS controls, particularly authentication and logging.
How to implement it
1. Name the standard you follow and stop there. OWASP ASVS, the SEI CERT coding standards or a language-specific equivalent are all defensible. What is not defensible is a procedure that says "secure coding practices are followed" without saying which.
2. Write the PCI DSS bullet into the procedure explicitly. State that applications handling account data implement the authentication controls in Requirement 8 and the logging in Requirement 10, so a developer reading the procedure learns it rather than inferring it.
3. Put a security activity in each stage, not a gate at the end. Threat modelling at design, a dependency check at build, an abuse case in test. Each is small, and together they are the evidence for the third bullet.
4. Keep it to the software you actually write. This control covers bespoke and custom software. Applying it to vendor products dilutes it and gives an assessor more to disagree with.
Where this commonly fails
- A standard adopted by name in a document nobody has opened since it was written.
- Security considered only at a pre-release review, when the requirement says each stage of the lifecycle.
- The PCI DSS bullet read as "we are a PCI DSS compliant company" rather than as an instruction about the code.
- Procedures that describe the ideal process while the team follows a different one, which the interviews in the rest of 6.2 will surface.
Related controls
Others in section 6.2:
| Control | What it requires |
|---|---|
| 6.2.2 | Software development personnel working on bespoke and custom software are trained at least once… |
| 6.2.3 | Bespoke and custom software is reviewed prior to being released into production… |
| 6.2.3.1 | If manual code reviews are performed for bespoke and custom software prior to release… |
| 6.2.4 | Software engineering techniques or other methods are defined and in use by software development… |
← 6.1.2 · All controls · 6.2.2 →
Source
The requirement text and testing procedures above are reproduced from PCI DSS v4.0.1 (June 2024), ©2006-2024 PCI Security Standards Council, LLC. All rights reserved. The commentary is our own.
The official standard is authoritative and also contains the Customized Approach Objective, applicability notes and guidance for this control. Download it from the PCI Security Standards Council document library. PCI DSS is a registered standard of the PCI Security Standards Council, LLC, which does not endorse this site. Nothing here is a substitute for advice from a Qualified Security Assessor.