Document Comparison
PCI-Secure-SLC-v1_0-ROC-Template-r1_0.pdf
→
PCI-Secure-SLC-ROC-Template-v1_1.pdf
59% similar
64 → 59
Pages
15415 → 15377
Words
173
Content Changes
From Revision History
- September 2019 1.0 Initial release of Report on Compliance (ROC) template for the PCI Secure Software Lifecycle Requirements and Assessment Procedures version 1.0.
Content Changes
173 content changes. 75 administrative changes (dates, page numbers) hidden.
Added
p. 4
• Secure Software Lifecycle Program Guide
Added
p. 26
2.4.b For a sample of software security assurance processes, the assessor shall Identify the software security assurance processes sampled for this test requirement.
Added
p. 29
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.
Describe how the assessor determined whether any failures or weaknesses in the implemented security assurance processes occurred.
If “no,” skip to 3.1. If “yes,” complete the remaining reporting instructions for this test requirement.
Describe how the assessor determined whether any failures or weaknesses in the implemented security assurance processes occurred.
If “no,” skip to 3.1. If “yes,” complete the remaining reporting instructions for this test requirement.
Added
p. 33
Describe how the assessor determined whether the software vendor utilizes open-source components in their software.
Added
p. 38
• Security testing is performed by authorized and objective vendor personnel or third parties.
Describe how the software vendor’s process ensures that security testing is
• Security-testing details including the tools used, their configurations, and the specific tests performed are recorded and retained. only performed by authorized and objective vendor personnel or third- parties.
4.1.c The assessor shall examine vendor evidence and interview personnel to confirm that personnel responsible for testing are knowledgeable and skilled in Identify the vendor evidence examined that confirms the findings for this test requirement.
Describe how the software vendor’s process ensures that security testing is
• Security-testing details including the tools used, their configurations, and the specific tests performed are recorded and retained. only performed by authorized and objective vendor personnel or third- parties.
4.1.c The assessor shall examine vendor evidence and interview personnel to confirm that personnel responsible for testing are knowledgeable and skilled in Identify the vendor evidence examined that confirms the findings for this test requirement.
Added
p. 42
Control Objective 5: Change Management The software vendor identifies and manages all software changes throughout the software lifecycle.
5.1.b For a sample of changes, the assessor shall examine software-specific Identify the changes sampled for this test requirement.
5.1.b For a sample of changes, the assessor shall examine software-specific Identify the changes sampled for this test requirement.
Added
p. 49
(continued on next page) Identify the vendor systems sampled for this test requirement.
Describe how vendor systems were tested to determine whether sensitive production data is resident on those systems.
Describe how vendor systems were tested to determine whether sensitive production data is resident on those systems.
Added
p. 51
8.1.b For a sample of vendor software, examine software-specific documentation and materials to confirm that the software vendor provides and maintains guidance on the secure configuration of each security-related option or parameter available in the vendor’s software.
Added
p. 53
8.3.b For a sample of software updates, examine secure implementation guidance as well as details of the software updates to confirm that as security-related options and parameters are updated or added, the secure implementation guidance is updated.
Removed
p. 4
• Secure Software Lifecycle Reporting Template (which will subsequently be referred to as the “Secure SLC ROC Reporting Template”) is for use with the PCI Software Security Framework
• Secure Software Lifecycle Standard Program Guide
• Secure Software Lifecycle Attestation of Compliance (AOC)
• Secure Software Lifecycle Standard Program Guide
• Secure Software Lifecycle Attestation of Compliance (AOC)
Modified
p. 4
• Secure Software Lifecycle Requirements and Assessment Procedures (“PCI Secure SLC Standard”) and is the mandatory template for Secure SLC Assessors completing a Secure SLC Assessment. The Secure SLC ROC Reporting Template provides reporting instructions and a reporting template for Secure SLC Assessors to use. Using this template assures a consistent level of reporting against the PCI Secure SLC Standard amongst assessors.
• Secure Software Lifecycle Requirements and Assessment Procedures (“PCI Secure SLC Standard”) Version 1.1 and is the mandatory template for Secure SLC Assessors completing a Secure SLC Assessment. The Secure SLC ROC Reporting Template provides reporting instructions and a reporting template for Secure SLC Assessors. Using this template assures a consistent level of reporting against the PCI Secure SLC Standard amongst assessors.
Modified
p. 4
Use of this Reporting Template is mandatory for all Secure SLC Assessment report submissions to PCI SSC.
Modified
p. 4
Do not delete any content from any place in this document, including this section and the versioning above. These instructions are important for the assessor as the report is written and for the recipient in understanding the context the responses and conclusions are made. Additional text or sections is permitted within reason, as noted before.
Do not delete any content from any place in this document, including this section and the versioning above. These instructions are important for the assessor as they complete reporting, but also provide context for the report recipient(s). The inclusion of additional text or sections is permitted within reason, as noted above.
Modified
p. 4
A Secure SLC Assessment involves thorough testing and assessment activities, from which the assessor will generate detailed work papers for each control objective and its associated test requirements. These work papers contain comprehensive records of the assessment activities including observations, configurations, process information, interview notes, documentation excerpts, references, screenshots, and other evidence collected during the assessment. The Secure SLC Report on Compliance (ROC) is effectively a summary of evidence derived from the assessor’s work papers to describe how the assessor …
A Secure SLC Assessment involves thorough testing and assessment activities, from which the assessor will generate detailed work papers for each control objective and its associated test requirements. These work papers contain comprehensive records of the assessment activities including observations, configurations, process information, interview notes, documentation excerpts, references, screenshots, and other evidence collected during the assessment. The Secure SLC Report on Compliance (ROC) is effectively a summary of evidence derived from the assessor’s work papers to describe how the assessor …
Modified
p. 4
This template should be used in conjunction with the latest versions of the following PCI Software Security Framework documents, available on the PCI SSC website at https://www.pcisecuritystandards.org.
This template should be used in conjunction with appropriate versions of the following PCI Software Security Framework documents, available on the PCI SSC website at https://www.pcisecuritystandards.org.
Modified
p. 11
Note: This date must be shown as the “Secure SLC ROC Completion Date” in the Secure SLC AOC.
Note: This date must be shown as the “Secure SLC ROC Completion Date” in Part 3d of the Secure SLC AOC.
Modified
p. 12
Note: See Appendix A Section A.3 for a detailed explanation of product categories and how they are used.
Note: See Section A.3 in the PCI Secure Software Lifecycle Program Guide for a detailed explanation of product categories and how they are used.
Modified
p. 12
(01) POS Suite/General (02) Payment Middleware (03) Payment Gateway/Switch (04) Payment Back Office (05) POS Admin (06) POS Specialized (07) POS Kiosk (08) POS Face-to-Face/POI (09) Shopping Cart / Store Front (10) Card-Not-Present (11) Automated Fuel Dispenser (12) Payment Component
(01) POS Suite/General (02) Payment Middleware (03) Payment Gateway/Switch (04) Payment Back Office (05) POS Admin (06) POS Specialized (07) POS Kiosk (08) POS Face-to-Face/POI (09) Shopping Cart / Store Front (10) Card-Not-Present (11) Automated Fuel Dispenser (12) Payment Component Other (please explain):
Modified
p. 16
Sample Type / Description (e.g. systems, software updates, etc.) Listing of All Items in Sample Set (unique system identifiers, software versions, etc.) Total Sampled Total Population Set-1 Software-development personnel sampled in 1.3.b.
Sample Type / Description (e.g. systems, software updates, etc.) Listing of All Items in Sample Set (unique system identifiers, software versions, etc.) Total Sampled Total Population Set-1 Software development personnel sampled in 1.3.b.
Modified
p. 16
Set-2 Software-development personnel sampled in 2.2.b.
Set-2 Software development personnel sampled in 2.2.b.
Modified
p. 16
Set-3 Software-development personnel sampled in 2.3.b.
Set-3 Software development personnel sampled in 2.3.b.
Modified
p. 19
5. Findings and Observations Control Objective 1: Security Responsibilities and Resources The software vendor’s senior leadership team establishes formal responsibility and authority for the security of the vendor’s products and services. The vendor allocates resources to execute the strategy and to ensure that personnel are appropriately skilled.
5. Findings and Observations Control Objective 1: Security Responsibilities and Resources The software vendor’s senior leadership team establishes formal responsibility and authority for the security of the software vendor’s products and services. The software vendor allocates resources to execute the strategy and to ensure that personnel are appropriately skilled.
Modified
p. 19
Control Objectives and Test Requirements Reporting Instructions Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) 1.1 Overall responsibility for the security of the vendor’s products and services is assigned by the vendor’s senior leadership team.
Control Objectives and Test Requirements Reporting Instructions Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) 1.1 Overall responsibility for the security of the software vendor’s products and services is assigned by the vendor’s senior leadership team.
Modified
p. 19
• Accountability for ensuring the security of the vendor’s products and services is formally assigned to an individual or team by the vendor’s senior leadership.
• Accountability for ensuring the security of the software vendor’s products and services is formally assigned to an individual or team by the software vendor’s senior leadership.
Modified
p. 19
• Responsibilities include keeping senior leadership informed of security updates, issues, and other matters related to the security of the vendor’s products and services.
• Responsibilities include keeping senior leadership informed of security updates, issues, and other matters related to the security of the software vendor’s products and services.
Modified
p. 19
• Updates are provided to senior leadership at least annually on the performance of and changes to the vendor’s software security policy and strategy (as described in Control Objective 2).
• Updates are provided to senior leadership at least annually on the performance of and changes to the software vendor’s software security policy and strategy described in Control Objective 2.
Modified
p. 19
Identify the last date senior leadership were updated on issues or other matters related to the security of the vendor’s products and services, or changes to the vendor’s software security policy and/or strategy.
Identify the last date senior leadership were updated on issues or other matters related to the security of the software vendor’s products and services, or changes to the software vendor’s software security policy and/or strategy.
Modified
p. 20
• Software security responsibilities are clearly defined and assigned to appropriate individuals or teams, including software-development personnel.
• Software security responsibilities are clearly defined and assigned to appropriate individuals or teams, including software development personnel.
Modified
p. 20
• Assignment of responsibilities for ensuring the security of the vendor’s products and services covers the entire software lifecycle.
• Assignment of responsibilities for ensuring the security of the software vendor’s products and services covers the entire software lifecycle.
Modified
p. 20
Describe what the assessor observed in the vendor evidence to conclude that the software security responsibilities assigned to vendor personnel cover the entire software lifecycle.
Describe what the assessor observed in the vendor evidence to conclude that the software security responsibilities assigned to software vendor personnel cover the entire software lifecycle.
Modified
p. 20
1.2.b The assessor shall interview a sample of responsible individuals, including software-development personnel, to confirm they are clearly aware of and understand their software security responsibilities.
1.2.b The assessor shall interview a sample of responsible individuals, including software development personnel, to confirm they are clearly aware of and understand their software security responsibilities.
Modified
p. 21
• A mature process is implemented and maintained for managing and maintaining software security skills for software-development personnel.
• A mature process is implemented and maintained for managing and maintaining software security skills for software development personnel.
Modified
p. 21
• The process includes a review at least annually to ensure software- development personnel are maintaining the necessary skills for the security responsibilities they have been assigned.
• The process includes a review at least annually to ensure software development personnel are maintaining the necessary skills for the security responsibilities they have been assigned.
Modified
p. 21
Identify the vendor evidence examined that confirms a process for ensuring software-development personnel maintain their software security skills is implemented and maintained in a manner consistent with this test requirement.
Identify the vendor evidence examined that confirms a process for ensuring software development personnel maintain their software security skills is implemented and maintained in a manner consistent with this test requirement.
Modified
p. 21
Describe what the assessor observed in the vendor evidence to conclude that the vendor’s process for managing and maintaining personnel skills is mature (i.e., is established, repeatable across personnel and geographic locations, and whose output or outcomes are predictable).
Describe what the assessor observed in the vendor evidence to conclude that the software vendor’s process for managing and maintaining personnel skills is mature (i.e., is established, repeatable across personnel and geographic locations, and whose output or outcomes are predictable).
Modified
p. 21
Describe where the vendor maintains the definitions of skills required for each role, responsibility and job function.
Describe where the software vendor maintains the definitions of skills required for each role, responsibility and job function.
Modified
p. 21
Summarize the vendor’s criteria for how software-development personnel are expected to maintain their individual skills in software security matters relevant to their specific role, responsibility, and job function.
Summarize the software vendor’s criteria for how software development personnel are expected to maintain their individual skills in software security matters relevant to their specific role, responsibility, and job function.
Modified
p. 21
Describe what the assessor observed in the vendor evidence that demonstrates the vendor performs reviews at least annually to ensure software-development personnel are maintaining the necessary skills for the security responsibilities they have been assigned.
Describe what the assessor observed in the vendor evidence that demonstrates the software vendor performs reviews at least annually to ensure software development personnel are maintaining the necessary skills for the security responsibilities they have been assigned.
Modified
p. 22
For the sample of software-development personnel, describe how the vendor evidence and interviews demonstrate that software-development personnel:
For the sample of software development personnel, describe how the vendor evidence and interviews demonstrate that software development personnel:
Modified
p. 23
Control Objectives and Test Requirements Reporting Instructions Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) 2.1 Regulatory and industry security and compliance requirements applicable to the vendor’s operations, products, and services and the data stored, processed, or transmitted by the vendor are identified and monitored.
Control Objectives and Test Requirements Reporting Instructions Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) 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.
Modified
p. 23
Describe where the vendor maintains the inventory of external regulatory and industry security and compliance requirements.
Describe where the software vendor maintains the inventory of external regulatory and industry security and compliance requirements.
Modified
p. 24
2.2.a The assessor shall examine vendor evidence to confirm the following:
Modified
p. 24
• A software security policy exists and is communicated to appropriate vendor personnel and business partners, including all software- development personnel.
• A software security policy exists and is communicated to appropriate software vendor personnel and business partners, including all software development personnel.
Modified
p. 24
• At a minimum, the policy covers all security and control objectives within this standard (either explicitly or implicitly).
• At a minimum, the policy covers all control objectives within this standard (either explicitly or implicitly).
Modified
p. 24
• The vendor’s senior leadership team has approved the software security policy.
• The software vendor’s senior leadership team has approved the software security policy.
Modified
p. 24
Describe what the assessor observed in the vendor evidence that confirms each control objective within this standard is covered in the vendor’s software security policy.
Describe what the assessor observed in the vendor evidence that confirms each control objective within this standard is covered in the software vendor’s software security policy.
Modified
p. 24
Describe what the assessor observed in the vendor evidence to conclude the vendor’s senior leadership have approved the software security policy.
Describe what the assessor observed in the vendor evidence to conclude the software vendor’s senior leadership have approved the software security policy.
Modified
p. 24
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.
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.
Modified
p. 25
• A strategy for ensuring the security of the vendor’s products and services is defined.
• A strategy for ensuring the security of the software vendor’s products and services is defined.
Modified
p. 25
• The security strategy is based on or aligned with industry-accepted methodologies.
• The software security strategy is based on or aligned with industry- accepted methodologies.
Modified
p. 25
• The software security strategy covers the entire lifecycle of the vendor’s software products and services.
• The software security strategy covers the entire lifecycle of the software vendor’s software products and services.
Modified
p. 25
• The security strategy is communicated to appropriate personnel, including software- development personnel.
• The software security strategy is communicated to appropriate personnel, including software development personnel.
Modified
p. 25
• The security strategy is reviewed at least annually and updated as needed (such as when business needs, external drivers, and products and services evolve).
• The software security strategy is reviewed at least annually and updated as needed (such as when business needs, external drivers, and products and services evolve).
Modified
p. 25
Identify the vendor evidence examined that confirms a strategy for ensuring the security of the vendor’s products and services is defined and maintained in a manner consistent with this test requirement.
Identify the vendor evidence examined that confirms a strategy for ensuring the security of the software vendor’s products and services is defined and maintained in a manner consistent with this test requirement.
Modified
p. 25
Identify the industry-accepted methodologies upon which the vendor’s software security strategy is based or with which it aligns.
Identify the industry-accepted methodologies upon which the software vendor’s software security strategy is based or with which it aligns.
Modified
p. 25
Describe what the assessor observed in the vendor evidence to conclude that the software security strategy covers the entire software lifecycle for the vendor’s products and services.
Describe what the assessor observed in the vendor evidence to conclude that the software security strategy covers the entire software lifecycle for the software vendor’s products and services.
Modified
p. 25
Describe what the assessor observed in the vendor evidence and discovered through interviews to conclude that the security strategy is updated when factors such as business needs, external drivers, and products and services evolve.
Describe what the assessor observed in the vendor evidence and discovered through interviews to conclude that the software security strategy is updated when factors such as business needs, external drivers, and products and services evolve.
Modified
p. 26
Describe what was discussed during the interviews that led the assessor to conclude the software-development personnel interviewed are aware of and understand the software security strategy.
Describe what was discussed during the interviews that led the assessor to conclude the software development personnel interviewed are aware of and understand the software security strategy.
Modified
p. 27 → 26
Describe where the vendor maintains the inventory of software security assurance processes.
Describe where the software vendor maintains the inventory of software security assurance processes.
Modified
p. 28 → 27
• Software security assurance processes clearly address specific rules and goals within the vendor’s software security policy.
• Software security assurance processes clearly address the specific rules and goals within the software vendor’s software security policy.
Modified
p. 28 → 27
• Software security assurance processes are aligned with the vendor’s software security strategy.
• Software security assurance processes are aligned with the software vendor’s software security strategy.
Modified
p. 28 → 27
• Vendor personnel, including software-development personnel, are assigned responsibility and accountability for the execution and performance of the security assurance process in accordance with Control Objective 1.2.
• Software vendor personnel, including software development personnel, are assigned responsibility and accountability for the execution and performance of the security assurance process in accordance with Control Objective 1.2.
Modified
p. 28 → 27
• The results or outcomes of each security assurance process are monitored in accordance with Control Objective 2.5.
• The results or outcomes of each security assurance process are monitored in accordance with Control Objective 2.6.
Modified
p. 28 → 27
For the software security assurance processes selected, describe what the assessor observed in the vendor evidence and discovered through interviews to conclude the processes are aligned with the vendor’s software security strategy.
For the software security assurance processes selected, describe what the assessor observed in the vendor evidence and discovered through interviews to conclude the processes are aligned with the software vendor’s software security strategy.
Modified
p. 28 → 27
For the software security assurance processes sampled, describe how the vendor evidence demonstrates that the results or outcomes of the software security assurance processes are monitored in accordance with Control Objective 2.5.
For the software security assurance processes sampled, describe how the vendor evidence demonstrates that the results or outcomes of the software security assurance processes are monitored in accordance with Control Objective 2.6.
Removed
p. 29
In Place N/A Not in Place 2.5.a The assessor shall examine vendor evidence, including the inventory of software security assurance processes, and interview personnel to confirm that evidence is generated and maintained for each security assurance process specified in the inventory described in 2.4.a.
Modified
p. 29 → 28
Identify the vendor evidence examined that confirms that the security assurance processes, specified in the inventory defined in 2.4.a, generate evidence that demonstrates their effectiveness.
Identify the vendor evidence examined that confirms that the security assurance processes generate evidence that demonstrates their effectiveness.
Modified
p. 29 → 28
2.5.b For a sample of security assurance processes, the assessor shall examine the 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.
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.
Removed
p. 30
In Place N/A Not in Place 2.6.a The assessor shall examine vendor evidence and interview personnel to confirm the following:
2.6.b For a sample of security assurance processes (as defined in Control Objective 2.4), the assessor shall interview personnel and examine evidence, including that generated by the security process (as described in Control Objective 2.5), to identify any failures or weaknesses in those security processes and to confirm that weak or ineffective processes were updated, augmented or replaced.
2.6.b For a sample of security assurance processes (as defined in Control Objective 2.4), the assessor shall interview personnel and examine evidence, including that generated by the security process (as described in Control Objective 2.5), to identify any failures or weaknesses in those security processes and to confirm that weak or ineffective processes were updated, augmented or replaced.
Modified
p. 30 → 29
Describe where the vendor maintains its criteria and justifications for how it defines weak or ineffective security assurance processes.
Describe where the software vendor maintains its criteria and justifications for how it defines weak or ineffective security assurance processes.
Modified
p. 31 → 30
Describe what the assessor observed in the vendor evidence to conclude that the weak or ineffective security assurance processes were updated, augmented or replaced.
Modified
p. 32 → 31
Summarize the vendor’s process for determining critical assets in the vendor’s software.
Summarize the software vendor’s process for determining critical assets in the vendor’s software.
Modified
p. 32 → 31
Describe where the vendor maintains the inventory of critical assets used by the vendor’s software.
Describe where the software vendor maintains the inventory of critical assets used by the vendor’s software.
Modified
p. 33 → 32
• The assessment accounts for all software inputs/outputs, process/data flows, trust boundaries and decision points, and how they may be exploited by an attack.
• The assessment accounts for all software inputs/outputs, process/data flows, trust boundaries and decision points, and how they may be exploited by an attacker.
Modified
p. 33 → 32
Describe what the assessor observed in the vendor evidence to conclude the vendor’s process accounts for all software inputs and outputs, process/data flows, and trust boundaries and decision points, and how they may be exploited by an attack.
Describe what the assessor observed in the vendor evidence to conclude the software vendor’s process accounts for all software inputs and outputs, process/data flows, and trust boundaries and decision points, and how they may be exploited by an attacker.
Modified
p. 33 → 32
Describe how and where the vendor maintains assessment results.
Describe how and where the software vendor maintains threat and design flaw assessment results.
Modified
p. 34 → 33
• An inventory of open-source components used in the software is maintained.
• An inventory of open-source components used in the vendor’s software is maintained.
Modified
p. 34 → 33
• The vendor monitors vulnerabilities in open-source components throughout their use or inclusion in the vendor’s software to determine when new vulnerabilities are identified.
• The software vendor monitors vulnerabilities in open-source components throughout their use or inclusion in the vendor’s software.
Modified
p. 34 → 33
• An appropriate patching strategy for the open-source components is defined.
• An appropriate patching strategy for open-source components is defined.
Modified
p. 34 → 33
Indicate whether the vendor utilizes open-source software components in their software (yes/no).
Indicate whether the software vendor utilizes open-source software components in their software (yes/no).
Modified
p. 34 → 33
Describe how and where the vendor maintains an inventory of open-source components used in the vendor’s software.
Describe how and where the software vendor maintains an inventory of open- source components used in the vendor’s software.
Modified
p. 34 → 33
Summarize how the vendor monitors vulnerabilities in open-source components throughout their use or inclusion in the vendor’s software.
Summarize how the software vendor monitors vulnerabilities in open-source components throughout their use or inclusion in the vendor’s software.
Modified
p. 34 → 33
Describe how the assessor arrived at the conclusion that the vendor’s patching strategy for open-source components is appropriate.
Describe how the assessor arrived at the conclusion that the software vendor’s patching strategy for open-source components is appropriate.
Modified
p. 35 → 34
Identify the vendor payment software sampled for this test requirement.
Identify the vendor software sampled for this test requirement.
Modified
p. 35 → 34
For the vendor payment software sampled, identify the date(s) of the most recent assessment of software threats and design weaknesses (as specified in 3.2.a) to confirm assessments are performed.
For the vendor software sampled, identify the date(s) of the most recent assessment of software threats and design weaknesses to confirm assessments are performed.
Modified
p. 35 → 34
For the vendor payment software sampled, describe what the assessor observed in the assessment results to conclude that the following were considered during the assessment:
For the vendor software sampled, describe what the assessor observed in the assessment results to conclude that the following were considered during the assessment:
Modified
p. 35 → 34
For the vendor payment software sampled, describe what the assessor observed in the assessment results to conclude that the entire code base was considered during the assessment, including:
For the vendor software sampled, describe what the assessor observed in the assessment results to conclude that the entire code base was considered during the assessment, including:
Modified
p. 36 → 35
Identify the vendor evidence examined that confirms a process is implemented for defining software-specific security requirements and implementing software security controls within the vendor’s software in a manner consistent with this test requirement.
Identify the vendor evidence examined that confirms a process is implemented for defining software-specific security requirements and implementing software security controls within the software vendor’s software in a manner consistent with this test requirement.
Modified
p. 36 → 35
Describe how the vendor evidence examined demonstrates that decisions on whether and how to mitigate a specific threat or design flaw are recorded, justified, and approved by appropriate personnel.
Describe how the vendor evidence examined demonstrates that decisions on whether and how to mitigate a specific threat or design flaw are recorded, justified, and approved by appropriate software vendor personnel.
Modified
p. 37 → 36
3.3.c The assessor shall examine vendor evidence, including software-specific assessment results, security requirements, and the implemented software security controls to confirm that security controls have been implemented to mitigate all identified threats and design flaws.
3.3.c The assessor shall examine vendor evidence to confirm that security controls have been implemented to mitigate all identified threats and design flaws.
Modified
p. 38 → 36
• A mature process exists to identify weak or ineffective security controls and to update, augment, or replace them.
• A mature process exists to identify weak or ineffective software security controls and to update, augment, or replace them.
Modified
p. 38 → 36
Identify the vendor evidence examined that confirms a process is implemented to identify and update weak or ineffective security controls in a manner consistent with this test requirement.
(continued on next page) Identify the vendor evidence examined that confirms a process is implemented to identify and update weak or ineffective software security controls in a manner consistent with this test requirement.
Modified
p. 38 → 36
Describe where the vendor defines and maintains effectiveness criteria for software security controls.
Describe where the software vendor defines and maintains effectiveness criteria for software security controls.
Modified
p. 38 → 37
• Weak or ineffective security controls are updated, augmented, or replaced in a timely manner upon detection and in accordance with Control Objective 3.3.
• Weak or ineffective security controls are updated, augmented, or replaced in a timely manner upon detection.
Modified
p. 38 → 37
Describe what the assessor observed in the vendor evidence and discovered through interviews to conclude security control effectiveness is monitored throughout the software lifecycle.
Describe what the assessor observed in the vendor evidence and discovered through interviews to conclude software security control effectiveness is monitored throughout the software lifecycle.
Modified
p. 38 → 37
Describe how the assessor determined that, upon detection of weak or ineffective security controls, the security controls are updated, augmented or replaced in an appropriately timely manner.
Describe how the assessor determined that, upon detection of weak or ineffective software security controls, the software security controls are updated, augmented or replaced in an timely manner.
Modified
p. 40 → 38
• Tools or methods used for security testing are appropriate for detecting applicable vulnerabilities and are suitable for the software architecture, development languages, and frameworks used in the development of the software.
• Tools or methods used for security testing are appropriate for detecting applicable vulnerabilities in the vendor’s software, and are suitable for the software architectures, and the software development languages and frameworks employed.
Modified
p. 40 → 38
(continued on next page) Identify the vendor evidence examined that confirms a process for testing software for the existence and emergence of vulnerabilities is implemented in a manner consistent with this test requirement.
(continued on next page Identify the vendor evidence examined that confirms a process for testing software for the existence and emergence of vulnerabilities is implemented in a manner consistent with this test requirement.
Modified
p. 40 → 38
Summarize how the vendor defines the tools and methods used for testing the vendor’s software for vulnerabilities.
Summarize how the software vendor defines the tools and methods used for testing the vendor’s software for vulnerabilities.
Removed
p. 41
• Security testing is performed by authorized and objective vendor personnel or third parties in accordance with Control Objective 1.3.
• Security-testing details, including the tools used, their configurations, and the specific tests performed, are recorded and retained.
Describe how the vendor’s process ensures that security testing is only performed by authorized and objective vendor personnel or third-parties.
• Security-testing details, including the tools used, their configurations, and the specific tests performed, are recorded and retained.
Describe how the vendor’s process ensures that security testing is only performed by authorized and objective vendor personnel or third-parties.
Modified
p. 41 → 39
Describe where the vendor maintains the inventory of identified vulnerabilities for the vendor’s software and software components.
Describe where the software vendor maintains the inventory of identified vulnerabilities for the vendor’s software and software components.
Modified
p. 41 → 39
4.1.b The assessor shall examine evidence, including software-specific security testing configuration and test results to confirm the following:
4.1.b The assessor shall examine evidence, including software-specific security testing configurations and test results to confirm the following:
Modified
p. 41 → 39
Describe how the assessor determined that security testing was performed by authorized and objective vendor personnel or third-parties.
Describe how the assessor determined that security testing was performed by authorized and objective software vendor personnel or third-parties.
Modified
p. 42 → 40
• Security testing tools settings, configurations, and recommended usage Identify the vendor evidence examined that confirms the findings for this test requirement.
• Security testing tools settings, configurations, and recommended usage Identify the individuals interviewed that confirm the findings for this test requirement.
Removed
p. 43
In Place N/A Not in Place 4.2.a The assessor shall examine vendor evidence and interview personnel to confirm the following:
Modified
p. 43 → 41
Summarize how the vendor prevents previously resolved vulnerabilities or similar vulnerabilities from being reintroduced into software.
Summarize how the software vendor prevents previously resolved vulnerabilities or similar vulnerabilities from being reintroduced into software.
Modified
p. 43 → 41
Describe where the vendor’s criteria for determining the criticality or severity of vulnerabilities and how to address them are defined and justified.
Describe where the software vendor’s criteria for determining the criticality or severity of vulnerabilities and how to address them are defined and justified.
Modified
p. 44 → 41
Identify the vendor software sampled for this test requirement..
4.2.b For a sample of vendor software, the assessor shall examine software- Identify the vendor software sampled for this test requirement.
Modified
p. 45 → 42
For the sampled software and vulnerabilities for which a decision was made not to provide a fix in accordance with the vendor’s defined criteria, describe how the assessor arrived at the conclusion that the vendor’s justification for not providing a fix in accordance with defined criteria is reasonable.
For the sampled software and vulnerabilities for which a decision was made not to provide a security fix in accordance with the vendor’s defined criteria, describe how the assessor arrived at the conclusion that the software vendor’s justification for not providing a fix is reasonable.
Modified
p. 46 → 43
• The process results in an inventory of all changes made to the software, including a record of the determined security impact.
• The process results in an inventory of all changes made to software, including a record of the determined security impact.
Modified
p. 46 → 43
Describe where the inventory of all changes made to the vendor’s software is maintained.
Describe where the software vendor maintains its inventory of all software changes.
Modified
p. 46 → 43
Summarize how the vendor ensures that all implemented changes are authorized by responsible personnel.
Summarize how the software vendor ensures that all implemented changes are authorized by responsible personnel.
Modified
p. 46 → 43
Summarize how the vendor ensures that the code creator and individual authorizing the change are accurately recorded in the inventory of changes.
Summarize how the software vendor ensures that the code creator and individual authorizing the change are accurately recorded in the inventory of changes.
Removed
p. 48
5.2.b For a sample of software updates, the assessor shall examine vendor evidence including change-specific documentation to confirm the following:
Modified
p. 48 → 44
• A formal system or methodology for uniquely identifying each version of the software is defined.
• A formal system or methodology for uniquely identifying each version of software is defined.
Modified
p. 48 → 44
• All changes to software functionality are clearly associated with a unique version of the software.
• All changes to software functionality are clearly associated with a unique software version.
Modified
p. 48 → 44
Summarize the vendor’s methodology for uniquely identifying the vendor’s software, including how the vendor arranges unique identifiers or version elements in a sequential and logical manner.
Summarize the software vendor’s methodology for uniquely identifying its software, including how the software vendor arranges identifiers or version elements in a sequential and logical manner.
Modified
p. 48 → 44
Describe what the assessor observed in vendor evidence and discovered through interviews to conclude that all changes to software functionality are associated with a unique version of the software.
Describe what the assessor observed in vendor evidence and discovered through interviews to conclude that all changes to software functionality are associated with a unique software version.
Modified
p. 48 → 45
• All changes to software functionality are clearly associated with a unique version of the software.
• All changes to software functionality are clearly associated with a unique software version.
Modified
p. 49 → 46
Identify the vendor evidence examined that confirms a process, mechanism and/or tools to protect the integrity of software code are implemented in a manner consistent with this test requirement.
Identify the vendor evidence examined that confirms that a process, mechanism and/or tools to protect the integrity of software code are implemented in a manner consistent with this test requirement.
Modified
p. 49 → 46
Summarize the vendor’s methods to protect the integrity of the software code.
Summarize how the software vendor protects the integrity of its software code.
Modified
p. 50 → 47
• Processes, mechanisms, and/or the use of tools results in the secure delivery of update code.
• Processes, mechanisms, and/or the use of tools results in the secure delivery of updated code.
Modified
p. 50 → 47
Identify the vendor evidence examined that confirms a process, mechanisms and/or tool(s) to ensure the integrity of software updates during delivery are implemented in a manner consistent with this test requirement.
Identify the vendor evidence examined that confirms processes, mechanisms and/or tool(s) to ensure the integrity of software updates during delivery are implemented in a manner consistent with this test requirement.
Modified
p. 50 → 47
Describe the process, mechanisms, and/or tools used by the vendor to ensure the integrity of software updates during delivery.
Describe the processes, mechanisms, and/or tools used by the vendor to ensure the integrity of software updates during delivery.
Modified
p. 50 → 47
Describe what the assessor observed in the vendor evidence and discovered through interviews to conclude that the implemented process, mechanism and/or tool(s) are reasonable and appropriate for protecting the update code.
Describe what the assessor observed in the vendor evidence and discovered through interviews to conclude that the implemented processes, mechanisms and/or tool(s) are reasonable and appropriate for protecting the updated code.
Modified
p. 50 → 47
Describe how the assessor determined that the implemented process, mechanism and/or tool(s) result in the secure delivery of update code.
Describe how the assessor determined that the implemented processes, mechanisms and/or tool(s) result in the secure delivery of updated code.
Modified
p. 51 → 48
Control Objectives and Test Requirements Reporting Instructions Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) 7.1 Sensitive production data is only collected and retained on vendor systems where there is a legitimate business or technical need.
Control Objectives and Test Requirements Reporting Instructions Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) 7.1 Sensitive productiondata is only collected and retained on software vendor systems where there is a legitimate business or technical need.
Modified
p. 51 → 48
• An inventory of sensitive production data captured or stored by the vendor’s products and services is maintained.
• An inventory of sensitive production data captured or stored by the software vendor’s products and services is maintained.
Modified
p. 51 → 48
• Vendor decisions to use sensitive production data are approved by appropriate personnel.
• Decisions to use sensitive production data are approved by appropriate software vendor personnel.
Modified
p. 51 → 48
• Vendor decisions to use sensitive production data are recorded and reasonably justified.
• Decisions to use sensitive production data are recorded and reasonably justified.
Modified
p. 51 → 48
Identify the location where the vendor maintains an inventory of sensitive production data that is captured or stored by the vendor’s products or services.
Identify the location where the software vendor maintains an inventory of sensitive production data captured or stored by the software vendor’s products or services.
Modified
p. 51 → 48
Describe what the assessor observed in the vendor evidence and discovered through interviews to conclude that the use of sensitive production data is approved by appropriate personnel.
Describe what the assessor observed in the vendor evidence and discovered through interviews to conclude that the software vendor’s use of sensitive production data is approved by appropriate software vendor personnel.
Modified
p. 51 → 48
Describe where vendor decisions to use sensitive production data are recorded.
Describe where software vendor decisions to use sensitive production data are recorded.
Modified
p. 51 → 48
Describe how the assessor arrived at the conclusion that the vendor justifications for using sensitive production data are reasonable.
Describe how the assessor arrived at the conclusion that the software vendor’s justifications for using sensitive production data are reasonable.
Modified
p. 52 → 49
7.2.a The assessor shall examine vendor evidence and interview personnel to confirm that a mature process exists to ensure sensitive production data is protected when retained on software vendor systems and is securely deleted when no longer needed.
Modified
p. 52 → 49
Identify the vendor evidence examined that confirms a mature process is implemented to ensure sensitive production data is protected when retained on vendor systems and securely deleted when no longer needed.
Identify the vendor evidence examined that confirms a mature process is implemented to ensure sensitive production data is protected when retained on software vendor systems and securely deleted when no longer needed.
Modified
p. 52 → 49
Summarize how the vendor ensures sensitive production data is protected when retained on vendor systems.
Summarize how the software vendor ensures sensitive production data is protected when retained on vendor systems.
Modified
p. 52 → 49
Describe the tools and/or methods used by the vendor to securely delete sensitive production data (i.e., render irretrievable) when no longer needed.
Describe the tools and/or methods used by the software vendor to securely delete sensitive production data (i.e., render irretrievable) when no longer needed.
Modified
p. 53 → 49
• Sensitive production data is not resident on vendor systems unless appropriate evidence of approval and justification exists.
• Sensitive production data is not resident on software vendor systems unless appropriate evidence of approval and justification exists.
Modified
p. 53 → 50
Describe what the assessor observed in the vendor evidence and on the sampled systems to conclude that sensitive production data is not resident on vendor systems unless justified and approved.
Describe what the assessor observed in the vendor evidence and on the sampled systems to conclude that all retention of sensitive production data on software vendor systems is justified and approved.
Modified
p. 54 → 51
Control Objectives and Test Requirements Reporting Instructions Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) 8.1 Security guidance and instructions are provided to stakeholders to guide them through the secure implementation and configuration of the software.
Control Objectives and Test Requirements Reporting Instructions Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) 8.1 The software vendor provides stakeholders with clear and thorough guidance on the secure implementation, configuration, and operation of its software.
Modified
p. 54 → 51
In Place N/A Not in Place 8.1.a The assessor shall examine vendor evidence, including the security guidance provided to stakeholders, and interview personnel to confirm the following:
In Place N/A Not in Place 8.1.a The assessor shall examine vendor evidence and interview personnel to confirm the following:
Modified
p. 54 → 51
• A mature process exists to produce, maintain, and make available security guidance and instructions for stakeholders.
• A mature process exists to produce, maintain, and make available to stakeholders guidance on the secure implementation, configuration, and operation of its software.
Modified
p. 54 → 51
• The security guidance includes documentation of all configurable security-related options and parameters for the vendor’s software, and instructions for properly configuring and securing those options and parameters.
• The implementation guidance includes documentation of all configurable security-related options and parameters for the vendor’s software, and instructions for properly configuring and securing each of those options and parameters.
Modified
p. 54 → 51
Identify the vendor evidence examined that confirms a process to produce, maintain, and make available security guidance and instructions for stakeholders is implemented in a manner consistent with this test requirement.
Identify the vendor evidence examined that confirms a process to produce, maintain, and make available to stakeholders guidance on the secure implementation, configuration, and operation of its software is implemented in a manner consistent with this test requirement.
Modified
p. 54 → 51
Summarize how the vendor makes security guidance and instructions available to stakeholders on the proper configuration of all security-related options and parameters available in the vendor’s software.
Summarize how the software vendor makes guidance on the proper configuration of all security-related options and parameters in the vendor’s software available to stakeholders.
Removed
p. 55
For the sample of vendor software, describe what was observed in the software-specific documentation and materials that led the assessor to conclude that the vendor has provided security configuration guidance for all security-related options and parameters available in the sampled software.
Modified
p. 56 → 52
In Place N/A Not in Place 8.2 The assessor shall examine vendor evidence, including the security guidance provided to stakeholders, to confirm the following:
In Place N/A Not in Place 8.2 The assessor shall examine vendor evidence, to confirm the following:
Modified
p. 56 → 52
• The security guidance includes instructions on how to securely install or initialize, configure, and maintain the software.
• The secure implementation guidance includes instructions on how to securely install or initialize, configure, and maintain the software.
Modified
p. 56 → 52
• The security guidance is sufficiently detailed.
• The secure implementation guidance is sufficiently detailed.
Modified
p. 56 → 52
• Evidence exists or is obtained to illustrate that following the security guidance results in a secure software configuration.
• Evidence exists or is obtained to illustrate that following the secure implementation guidance results in a secure software configuration.
Modified
p. 56 → 52
Describe the rationale used by the assessor to determine whether the vendor’s security guidance is sufficiently detailed for stakeholders.
Describe the rationale used by the assessor to determine whether the software vendor’s secure implementation guidance is sufficiently detailed for stakeholders.
Modified
p. 56 → 52
Describe what the assessor observed in the vendor evidence to conclude that following the security guidance results in a secure software configuration.
Describe what the assessor observed in the vendor evidence to conclude that following the secure implementation guidance results in a secure software configuration.
Removed
p. 57
• The process to produce and maintain security guidance includes generation of updated guidance when new software updates are released, or security-related options or parameters are introduced or modified.
Modified
p. 57 → 52
Identify the vendor evidence examined that confirms a process is implemented in a manner consistent with this test requirement.
(continued on next page) Identify the vendor evidence examined that confirms a process is implemented in a manner consistent with this test requirement.
Modified
p. 57 → 52
Identify the individuals interviewed that confirm the findings for this test requirement.
• The process to produce and maintain secure implementation guidance includes generation of updated guidance when new Identify the individuals interviewed that confirm the findings for this test requirement.
Modified
p. 57 → 53
• Security guidance is reviewed at least annually for accuracy even if updates to security-related options and parameters are not issued.
• Secure implementation guidance is reviewed at least annually for accuracy even if updates to security-related options and parameters are not issued.
Modified
p. 57 → 53
Identify the date of the last security guidance review to confirm a review is performed at least annually.
Identify the date of the last secure implementation guidance review to confirm a review is performed at least annually.
Modified
p. 57 → 53
Describe what the assessor observed in the vendor evidence or discovered through interviews to conclude that security guidance is reviewed even if updates to security-related options and parameters are not issued.
Describe what the assessor observed in the vendor evidence or discovered through interviews to conclude that secure implementation guidance is reviewed even if updates to security- related options and parameters are not issued.
Modified
p. 58 → 53
Identify any other vendor evidence / details of the software updates examined (such as release notes, etc.) that confirm the findings for this test requirement.
Identify any other vendor evidence or details of the software updates examined (such as release notes, etc.) that confirm the findings for this test requirement.
Modified
p. 58 → 53
For the software updates sampled, describe what the assessor observed in the security guidance and details of the software updates to conclude that security guidance was updated when security-related options and parameters were updated.
For the software updates sampled, describe what the assessor observed in the secure implementation guidance and details of the software updates to conclude that security guidance was updated when security-related options and parameters were updated or added.
Modified
p. 59 → 54
• A mature process exists to support open, bi-directional communications with stakeholders for reporting and receiving security information regarding the vendor’s products and services.
• A mature process exists to support open, bi-directional communications with stakeholders for reporting and receiving security information regarding the software vendor’s products and services.
Modified
p. 59 → 54
• The vendor maintains resources to respond to reports or inquiries regarding the security of the vendor’s products and services.
• The software vendor maintains resources to respond to reports or inquiries regarding the security of the vendor’s products and services.
Modified
p. 59 → 54
Identify the vendor evidence examined that confirms a process to support open, bi-directional communications with stakeholders for reporting and receiving security information regarding the vendor’s products and services is implemented in a manner consistent with this test requirement.
Identify the vendor evidence examined that confirms a process to support open, bi-directional communications with stakeholders for reporting and receiving security information regarding the software vendor’s products and services is implemented in a manner consistent with this test requirement.
Modified
p. 59 → 54
Summarize how the vendor enables stakeholders to report and receive information on security issues and mitigation options in relation to the vendor’s products and services.
Summarize how the software vendor enables stakeholders to report and receive information on security issues and mitigation options in relation to the software vendor’s products and services.
Modified
p. 59 → 54
Summarize how the vendor maintains resources to respond to reports and inquiries regarding the security of the vendor’s products and services.
Summarize how the software vendor maintains resources to respond to reports and inquiries regarding the security of the software vendor’s products and services.
Removed
p. 60
Describe what the assessor observed in the vendor evidence and discovered through interviews to conclude that stakeholder are notified about security updates in a timely manner.
Modified
p. 61 → 55
Summarize how the vendor ensures risk mitigation instructions are provided to stakeholders for known vulnerabilities and exploits for which a timely patch is not provided.
Summarize how the software vendor ensures risk mitigation instructions are provided to stakeholders for known vulnerabilities and exploits for which a timely patch is not provided.
Modified
p. 61 → 55
9.3.b For a sample of software security updates, examine stakeholder communications, product-specific documentation, security-testing results, and other materials to confirm that where known vulnerabilities are not addressed in the security updates, risk mitigation instructions are provided to stakeholders.
9.3.b For a sample of software security updates, examine stakeholder communications, product-specific documentation, security-testing results, or other materials to confirm that where known vulnerabilities are not addressed in the security updates, risk mitigation instructions are provided to stakeholders.
Modified
p. 61 → 55
Identify the stakeholder communications, product-specific documentation, security- testing results, and other materials examined that confirm the findings for this test requirement.
Identify the stakeholder communications, product-specific documentation, security- testing results, or other materials examined that confirm the findings for this test requirement.
Modified
p. 61 → 55
For each of the software security updates sampled, describe what the assessor observed in the stakeholder communciations, product-specific documentation, security-testing results, and other materials that confirm that stakeholders are provided risk mitigation instructions when a patch to address a known vulnerability not readily available.
For each of the software security updates sampled, describe what the assessor observed in the stakeholder communciations, product-specific
Modified
p. 62 → 57
Summarize how the vendor makes change details easily accessible to stakeholders.
Summarize how the software vendor makes change details easily accessible to stakeholders.
Modified
p. 63 → 57
• Change summary information accurately reflects the changes made to the software (see Control Objective 5.2).
• Change summary information accurately reflects the changes made to the software.