PCI DSS 6.2.4: Software engineering techniques or other methods are defined and in use by software development
PCI DSS v4.0.1 control 6.2.4: 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
Software engineering techniques or other methods are defined and in use by software development personnel to prevent or mitigate common software attacks and related vulnerabilities in bespoke and custom software, including but not limited to the following:
- Injection attacks, including SQL, LDAP, XPath, or other command, parameter, object, fault, or injection-type flaws.
- Attacks on data and data structures, including attempts to manipulate buffers, pointers, input data, or shared data.
- Attacks on cryptography usage, including attempts to exploit weak, insecure, or inappropriate cryptographic implementations, algorithms, cipher suites, or modes of operation.
- Attacks on business logic, including attempts to abuse or bypass application features and functionalities through the manipulation of APIs, communication protocols and channels, client-side functionality, or other system/application functions and resources. This includes cross-site scripting (XSS) and cross-site request forgery (CSRF).
- Attacks on access control mechanisms, including attempts to bypass or abuse identification, authentication, or authorization mechanisms, or attempts to exploit weaknesses in the implementation of such mechanisms.
- Attacks via any “high-risk” vulnerabilities identified in the vulnerability identification process, as defined in Requirement 6.3.1.
Summary
Your developers use named techniques to prevent the specific attack classes the standard lists, and can show what those techniques are.
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.4 | Examine documented procedures and interview responsible software development personnel to verify that software engineering techniques or other methods are defined and in use by developers of bespoke and custom software to prevent or mitigate all common software attacks as specified in this requirement. |
The one control in Requirement 6 that is about how software is written rather than how it is managed, and its list is explicit: injection, attacks on data and data structures, attacks on cryptography usage, attacks on business logic (which the standard says includes XSS and CSRF), attacks on access control mechanisms, and anything your own 6.3.1 ranking called high-risk. That last bullet is the one that makes this control specific to you rather than generic: whatever your vulnerability process flags, your engineering practice has to answer. The single procedure examines your documented techniques and interviews developers, so it is checkable by conversation: a documented practice the team cannot describe is the usual failure.
What to prepare
- The documented software engineering techniques, mapped to the attack classes in the requirement rather than listed generically.
- Evidence they are in use: code review checklists, framework or library choices, static and dependency analysis in the pipeline.
- Developer training records for secure coding, which 6.2.2 covers and this control leans on.
- The link to the high-risk vulnerabilities from 6.3.1, showing they are addressed in development and not only in patching.
How to implement it
1. Answer each named class, in writing. "We follow OWASP" is not a technique. Parameterised queries answer injection; a framework that escapes by default and an anti-CSRF token answer the business-logic bullet; a vetted crypto library used through one wrapper answers the cryptography bullet.
2. Prefer the technique that cannot be forgotten. A linter rule, a framework default or a type that makes the unsafe call impossible survives staff turnover; a paragraph in a wiki does not, and it is developers the procedure interviews.
3. Cover business logic explicitly. It is the bullet with no tool: authorisation on every endpoint, server-side re-checking of anything the client decided, and API sequences that cannot be replayed out of order.
4. Close the loop with 6.3.1. If your ranking identifies a high-risk class you keep seeing, this control expects the engineering practice to change, not just the individual instances to be patched.
Where this commonly fails
- A secure coding policy nobody on the team can describe, which the interview finds immediately.
- Injection handled and the cryptography bullet unanswered, because nobody owns "how we use crypto".
- Business logic treated as covered by a scanner, when the tools that find injection do not find broken authorisation.
- The high-risk bullet ignored, so the control reads as generic advice rather than as something derived from your own environment.
Related controls
This control refers to 6.3.1.
Others in section 6.2:
| Control | What it requires |
|---|---|
| 6.2.1 | Bespoke and custom software are developed securely… |
| 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.3.1 · All controls · 6.3.1 →
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.