PCI Secure Software Lifecycle v1.1

Control Objectives:
2.1 Regulatory and industry security and compliance requirements applicable to the software vendor’s operations, products, and services and the data stored, processed, or transmitted by the software vendor are identified and monitored.
Test Requirements:
2.1 The assessor shall examine vendor evidence and interview personnel to confirm the following: 

Guidance:
Many organizations are subject to requirements for the protection of certain types of information and data such as personally identifiable information (PII), cardholder data (CHD), and protected health information (PHI). 
Software vendors should maintain awareness of evolving industry and regulatory requirements applicable to their operations and products. Maintaining ongoing awareness of external security and compliance obligations allows the software vendor to ensure its processes adequately address those requirements at all times, including whenever those requirements are updated or new requirements are introduced. 
Evidence to support this control objective might include documented policies and processes, internal standards, requirement mappings, internal presentations, training materials, or any other documentation or records that clearly and consistently illustrate that the software vendor has made reasonable efforts to understand and monitor its external security and compliance requirements. 

Control Objectives:
2.2 A software security policy is defined and establishes the specific rules and goals for ensuring the software vendor’s products and services are designed, developed, and maintained to be secure, resistant to attack, and in a manner that satisfies the software vendor’s security and compliance obligations.
Test Requirements:
2.2.a The assessor shall examine vendor evidence to confirm the following: 

2.2.b The assessor shall interview a sample of software development personnel to confirm they are aware of and understand the software security policy. 
Guidance:
Software vendors must establish a company-wide software security policy to ensure that all individuals or teams⎯including relevant business partners⎯involved in software design, development, and maintenance are aware and have a consistent understanding of how the vendor’s software products and services should be securely built and maintained, and how any critical assets should be handled. The software security policy (or policies) should be known and thoroughly understood by those with the responsibility to ensure they are met, as well as those individuals and teams who have the ability to affect the security of the software vendor’s products and services. The software vendor’s senior leadership team should openly support the establishment and enforcement of the software security policy through appropriate communications to software vendor personnel, to reinforce the importance of software security to the vendor organization and its leadership. 
Evidence to support this control objective might include documented policies and processes, presentations, mission statements, e-mails, company intranet content, or other formal company communications that clearly and consistently illustrate efforts to ensure appropriate personnel and business partners are aware of and understand the vendor’s software security policy 

Control Objectives:
2.3 A formal software security strategy for ensuring the security of the software vendor’s products and services and satisfying its software security policy is established and maintained.
Test Requirements:
2.3.a The assessor shall examine vendor evidence and interview responsible personnel to confirm the following:

 2.3.b The assessor shall interview a sample of software development personnel to confirm they are aware of and understand the software security strategy.
Guidance:
A software security strategy is a high-level plan, roadmap, or methodology for ensuring the secure design, development, and maintenance of the software vendor’s products and services, and adherence to the software vendor’s software security policy. 
Software vendors should either adopt existing or develop their own frameworks or methodologies in accordance with industry-accepted practices for secure software lifecycle management. By aligning its software security strategy with industry-accepted methodologies, the software vendor is less likely to overlook important aspects of secure software lifecycle management. 
Software vendors that develop their own methodologies should understand how they differ from industry-accepted methodologies, identify any gaps, and ensure that sufficient evidence is maintained to clearly illustrate how their methodologies are at least as effective as those accepted by the industry. Examples of industry-accepted methodologies that are commonly used as benchmarks for secure software development and management include, but are not limited to, current versions of: 

The software security strategy should evolve as internal factors— such as the software vendor’s business strategy or product/service offerings—or external factors—such as external security and compliance requirements—evolve. Therefore, the software security strategy is not static and should be periodically reviewed and updated to maintain alignment with business needs and priorities. 
Evidence to support this requirement might include documented security plans or methodologies, presentations, policies and processes, training materials, meeting minutes, interviewer notes, e-mails or executive communications, mappings, or references to industry-accepted methodologies, gap analysis results, or any other records or documentation that clearly and consistently illustrates that the vendor has made a reasonable effort to develop, maintain, and keep current a formal strategy for satisfying the vendor’s software security policy. 

Control Objectives:
2.4 Software security assurance processes are implemented and maintained throughout the entire software lifecycle.
Note: This control objective focuses on the overall management of security assurance processes and provides the foundation for specific assurance processes defined within this document
Test Requirements:
2.4.a The assessor shall examine vendor evidence and interview personnel to confirm the following:

2.4.b For a sample of software security assurance processes, the assessor shall examine vendor evidence and interview personnel to confirm the following: 

Guidance:
Software security assurance processes are activities that are implemented to carry out the software vendor’s software security strategy and to facilitate secure software design, development, and maintenance. To ensure that security and compliance requirements are met, software security policy is satisfied, and the software vendor’s products and services are secure and resistant to attack, software vendors need to define such processes throughout all phases of the software lifecycle. These may include security “checkpoints,” which are distinct points within the software development process where software is checked to make sure security requirements are met. Examples of software security assurance processes and controls include software-design reviews, automated code reviews, security-specific functional testing, and change-management processes. For organizations that leverage Agile software development methodologies, security checkpoints may be incorporated into the “story” acceptance criteria or the criteria for determining when work is considered “done.” 
Evidence to support this requirement might include documented policies and processes, security-control inventories, output from Governance Risk and Compliance (GRC) or other management tools, software-specific requirements documentation, or any other evidence that clearly and consistently identifies the software security assurance processes that have been implemented and illustrates that the security assurance processes are appropriate for the function they are intended to provide. Additionally, evidence to illustrate the software security assurance processes are implemented properly may include system or process outputs such as threat models, security test results, bug tracking data, audit log data, incident response, etc. 

Control Objectives:
2.5 Evidence is generated and maintained to demonstrate the effectiveness of software security assurance processes.
Test Requirements:
2.5.a The assessor shall examine vendor evidence, including the inventory of software security assurance processes described in Test Requirement 2.4.a, and interview personnel to confirm that evidence is generated and maintained for each security assurance process.
2.5.b For a sample of security assurance processes, the assessor shall examine evidence and other output from the processes and interview personnel to confirm the evidence generated for each process reasonably demonstrates the process is operating effectively and as intended. 
Guidance:
To demonstrate the effectiveness of software security assurance processes, evidence should be generated and maintained for each process to illustrate that it directly results in or contributes to the expected security outcomes—e.g., fewer vulnerabilities or greater resistance to attacks. 
Evidence needs to be frequently collected and kept up to date to ensure it accurately reflects the ongoing effectiveness of security assurance processes. Without a track record of performance for software security assurance processes, it becomes almost impossible to effectively perform root-cause analysis when such processes fail to produce the expected results. 
Evidence to support this objective might include security control and evidence generation inventories, vulnerability reports, penetration testing results, or any other records and evidence that clearly and consistently illustrates evidence is generated for each software security assurance process and that the evidence clearly illustrates the effectiveness of the processes. 

Control Objectives:
2.6 Failures or weaknesses in software security assurance processes are detected. Weak or ineffective security assurance processes are updated, augmented or replaced.
Test Requirements:
2.6.a The assessor shall examine vendor evidence and interview personnel to confirm the following: 

2.6.b For a sample of the security assurance processes identified in Control Objective 2.4, the assessor shall interview personnel and examine any additional evidence necessary to determine if any failures or weaknesses in those security processes occurred, and to confirm that weak or ineffective processes were updated, augmented or replaced.
Guidance:
Software vendors should monitor their security assurance processes to confirm that they remain appropriate (i.e., fit for purpose) and effective for their intended purpose and function. For example, the use of manual code reviews may be sufficient to detect all coding errors and vulnerabilities for software with a very limited code base. However, as the code base grows, the use of manual code reviews for the same purpose becomes increasingly impractical or insufficient, and automated testing tools (such as automated static-code scanners and dynamic software-analysis tools) should be utilized. 
One method for detecting weak or ineffective security controls is to define a set of metrics or trends that can be used to measure the effectiveness of security assurance processes. For example, the results from a vendor’s security testing may provide greater insight into the effectiveness of security assurance processes. If security tests repeatedly find vulnerabilities within the software, it may be an indication that applicable security assurance processes are not being executed properly or working as intended. Another method to detect weak or ineffective security assurance processes would be to perform regular reviews of those processes and the evidence generated by those processes to verify they continue to be appropriate for their intended purpose. 
Evidence to support this requirement might include process-generated evidence, security test results, root-cause analysis, documented remediation actions, or any other evidence that clearly and consistently illustrates that the effectiveness of software security assurance processes is monitored, failures and weaknesses are detected, and security assurance processes are updated, augmented or replaced when no longer effective at satisfying their intended purpose.