Document Diff - PCI Watch

Added p. 5

Tables have been included in this template to assist with the reporting process for certain lists and other information as appropriate. You can modify the tables in this template to increase or decrease the number of rows or to change column width. The assessor may add appendices to include relevant information that is not addressed by the current organization. However, the assessor must not remove any details from the tables provided in this document. Customization is acceptable, such as the addition of company logos, but should be limited to the title page and the headers for the remainder of the document.

Software Security Framework

• Secure Software Requirements and Assessment Procedures Software Security Framework

• Secure Software Program Guide Software Security Framework

• Secure Software Attestation of Validation Software Security Framework

• Glossary of Terms, Abbreviations, and Acronyms Software Security Framework

• Qualification Requirements for Assessors

Table 1. Findings and Observations Control Objectives and Test Requirements Reporting …

Added p. 21

Reference Number Individual’s Name Role / Job Title Organization Summary of Topics Covered (high-level summary only)

Added p. 22

Reference Number Test Type / Description (e.g., type of test performed, forensic tools used, etc.) Test Scope (e.g., software components and/or features evaluated) Control Objectives Covered (No generic references) Test-1 Manual source code review User authentication module 5.1, 5.2, 5.3

Added p. 26

Describe any discrepancies that were found between the information obtained through documentation and evidence review and information obtained through software testing.

Identify the documentation and evidence examined in support of this test requirement, including the documentation and evidence examined in 1.1.a.

Added p. 27

Describe any discrepancies that were found between the information obtained through the documentation and evidence reviews and the information obtained through the software testing.

Identify the documentation evidence examined in support of this test requirement.

Added p. 28

Describe each of the configuration options that can impact the security of sensitive data.

Added p. 30

Describe any discrepancies found between the sensitive data identified through the documentation and evidence reviews in 1.1.a and the sensitive data identified through the documentation and evidence reviews in this test requirement.

Added p. 30

Describe what the assessor observed in the documentation, evidence, and software test results that confirms whether any sensitive functions or sensitive resources are provided by third- party software or systems.

Added p. 31

Describe any documentation and evidence examined in support of this test requirement, including the documentation and evidence examined in 1.2.a.

Describe what the assessor observed in the documentation and evidence examined that confirms the software vendor has identified the confidentiality, integrity, and resiliency requirements for each critical asset.

Describe how the software vendor’s inventory of all critical assets is maintained (e.g., the format, location, etc.).

Describe any discrepancies found between the information obtained through the documentation and evidence reviews and the information obtained through the software testing.

Added p. 33

Describe what the assessor observed in the documentation, evidence, and software test results that confirms whether the software relies on external resources for authentication.

Describe what the assessor observed in the documentation, evidence and software test results that confirms determines whether any of the APIs or other interfaces identified in 2.1.a rely on external resources for the protection of sensitive data during transmission.

If “yes,” describe each of the methods implemented to ensure proper protection of sensitive data remains in place and why the methods are appropriate for their intended purpose.

Added p. 35

Note: The assessor should reference the vendor threat information defined in Control Objective 4.1 for this item.

Describe what the assessor observed in the documentation, evidence, and software test results that confirms whether any vulnerabilities exist in exposed software functions, APIs, or other interfaces.

Added p. 36

Describe each of the mitigations implemented in the software to mitigate the risks posed by the vulnerabilities in the exposed methods or services, and why each mitigation is appropriate for its intended purpose.

Describe the software vendor’s justification for the software’s use of known vulnerable functions, protocols, and ports, and how the assessor concluded the vendor’s justification(s) are reasonable, given the risks involved.

Note: This test requirement is redundant with test requirement 2.1.a. Reporting instructions are intentionally left blank. No further instruction needed.

Describe what the assessor observed in the documentation, evidence, and software test results that confirms that all software functions exposed by third-party modules are either disabled or unable to be accessed by default.

Describe each of the third-party modules or functions that are exposed by default and the software vendor’s justification for doing so. For each instance where third- party modules or functions are exposed by default, also describe why the …

Added p. 38

Describe any circumstances that exist that prevent security controls, features, and functions from being enabled upon installation (for example, the software is only available as a service).

Added p. 39

Identify the documentation and evidence examined that contains the software vendor’s implementation guidance for properly enabling each of the security controls, features, and functions that require user input or interaction prior to being enabled.

2.2.d The assessor shall examine vendor evidence and test the software to confirm that following the software vendor’s implementation guidance required in Control Objective 12.1 results in all security-relevant software security controls, features, and functions being enabled prior to the software enabling processing of sensitive data.

Note: The assessor should refer to evidence obtained in the testing of Control Objectives 1, 5, and 7 to determine the authentication and access control mechanisms, keys, and other critical assets used for authentication.

Describe any discrepancies found between the information obtained through the documentation and evidence reviews in 2.3.a and the information obtained through the software testing performed in this test requirement.

Identify the documentation and evidence examined that contains the software vendor’s …

Added p. 43

Describe the mechanisms implemented by the software to prevent unauthorized access, exposure, or modification of critical assets.

Identify the documentation and evidence examined that contains the software vendor’s implementation guidance on properly configuring such mechanisms.

Describe any discrepancies between the information obtained through the documentation and evidence reviews in 2.4.a and the information obtained through the software testing in this test requirement.

Describe what the assessor observed in documentation, evidence and software test results that confirms that the software does not use legacy features of the intended execution environment, and that only recent and secured functions are implemented.

Added p. 45

Describe what the assessor observed in documentation, evidence, and software test results that confirms that all exposed software functions (APIs and other interfaces) are protected from unauthorized use and modification.

Describe any discrepancies found between the functions and services identified through the documentation and evidence reviews and the functions and services identified through the software testing.

Describe what the assessor observed in the documentation, evidence, and software test results that indicates that all persistent sensitive data stored or retained for debugging, error finding, or testing purposes are protected in accordance with Control Objective 6.

Describe the software configuration options, mechanisms, etc., that must be enabled explicitly and authorized by the user before any storage and/or retention of persistent sensitive data is permitted by the software.

Describe the specific features and functions implemented by the software to ensure that all persistent sensitive data retained for debugging, error finding, or testing are securely deleted upon closure …

Added p. 50

If “no,” skip to 3.2.d.

Describe what the assessor observed in the documentation, evidence, and software test results that indicate that all transient sensitive data stored or retained for debugging, error finding, or testing purposes are protected in accordance with Control Objective 6.

Describe the software configuration options, mechanisms, etc., that must be enabled explicitly and authorized by the user before any storage and/or retention of transient sensitive data for debugging, error finding, or testing is permitted.

Describe the specific features and functions implemented by the software to ensure that all transient sensitive data retained for debugging, error finding, or testing is securely deleted upon closure of the software in accordance with Control Objective 3.4.

Added p. 51

Describe what the assessor observed in the documentation and evidence that confirms determines whether the software enables users to configure retention periods for transient sensitive data.

Identify the documentation and evidence examined that contains the software vendor’s implementation guidance for configuring the retention periods for transient sensitive data stored or retained by the software.

Describe what the assessor observed in the software vendor’s implementation guidance that indicates clear and sufficient instruction is provided to stakeholders on configuring the retention periods for transient sensitive data and configuring the secure deletion of such data when no longer needed.

Describe what the assessor observed in the software testing results that confirms the software does not provide for any additional storage or retention of sensitive data beyond that which was identified in the testing for Control Objectives 3.1 and 3.2.

Describe what the assessor observed in the documentation, evidence, and software test results that confirms whether any transient …

Added p. 53

Identify the software structures and locations used to store each item of sensitive data (persistent or transient), where such data is stored outside of temporary variables during retention.

For each item of sensitive data (persistent or transient) that is stored outside of temporary variables during retention, describe what the assessor observed in the documentation, evidence, and software test results that confirms that all instances of sensitive data stored outside of temporary variables during retention are protected using either strong cryptography or other methods that provide equivalent security.

Added p. 54

If “no,” skip to 3.3.e.

For each of the cryptographic methods used, describe what the assessor observed in the documentation, evidence, and software test results that confirms that each cryptographic implementation complies with Control Objective 7.

Added p. 55

Describe any discrepancies found between the protection methods identified through the documentation and evidence reviews and the protection methods identified through the software testing.

Identify the documentation and evidence examined that contains the software vendor’s implementation guidance for instructing users where and how to configure all protection mechanisms that require user input or interaction.

Added p. 57

Describe any additional software tests performed to support of this test requirement, including the tool(s) or method(s) used and the scope of each test.

Identify all platform and implementation issues that may complicate the erasure of transient sensitive data.

Identify the methods implemented to ensure non-transient sensitive data is rendered unrecoverable.

Describe what the assessor observed in the software testing results that confirms the methods implemented by the software to render non-transient sensitive data unrecoverable are implemented correctly.

• and to confirm what methods have been implemented to minimize the risk posed by these complications.

Identify all platform and implementation issues that complicate the erasure of transient sensitive data.

Identify each of the methods implemented to minimize the risk posed by these complications.

Describe what the assessor observed in in the software testing results that confirms that the methods implemented by the software to render transient sensitive data unrecoverable are implemented correctly and applied to all transient …

Added p. 67

Describe what the assessor observed in the documentation, evidence, and software test results that confirms whether any software mitigations or protection mechanisms rely on configurable settings within the software.

Describe what the assessor observed in the documentation, evidence, and software test results that indicates that settings or values required to configure threat mitigations cannot be disabled, removed, or bypassed without requiring strong user authentication and authorization.

Added p. 68

Describe what the assessor observed in the documentation, evidence, and software test results that confirms whether software protection mechanisms rely on features of the execution environment.

Identify the documentation and evidence that contains the software vendor’s guidance on enabling, configuring, and using protection methods provided by the execution environment.

Added p. 70

Describe what the assessor observed in the documentation and evidence that confirms that authentication requirements are defined for all roles based on critical-asset classification, type of access, and level of privilege.

Added p. 73

Identify the documentation and evidence that contains the software vendor’s guidance on configuring unique credentials for each program or system to which automated access to critical assets is provided via APIs or other interfaces.

If “yes,” describe what the assessor observed in the documentation, evidence, and software test results that indicate that the authentication mechanisms that supply its identification parameters in this way are protected.

Describe what the assessor observed in the software vendor’s guidance that confirms that users are instructed not to share identification and authentication parameters between individuals or programs.

Describe what the assessor observed in the documentation and evidence that indicates that the protection mechanisms implemented to mitigate the probability and impact of potential attacks on the software’s authentication methods are appropriate for their intended purpose and that any residual risk has been reasonably justified.

Describe any discrepancies found between the access provided to critical assets identified through the documentation and …

Added p. 81

Describe what the assessor observed in the documentation, evidence, and software test results that indicates that the security properties, upon which the protection mechanisms rely, exist for all platforms included in the software evaluation.

Describe what the assessor observed in the documentation, evidence, and software test results that indicates that the protection mechanisms that rely on execution environment security properties are appropriate for the type of sensitive data they are to protect.

Added p. 82

Describe what the assessor observed in the documentation, evidence, and software test results that confirms whether software protection mechanisms rely on third-party software security properties to safeguard sensitive data.

Describe what the assessor observed in the documentation, evidence, and software test results that indicates that the protection mechanisms that rely on third-party software security properties are appropriate for the type of sensitive data they are to protect.

Describe what the assessor observed in the documentation and evidence that confirms that there are no unmitigated vulnerabilities in the third-party software, whose security properties are relied upon by the software’s protection methods.

Describe what the assessor observed in the documentation, evidence, and software test results that confirms that all transmissions of sensitive data outside of the physical execution environment are encrypted prior to transmission using strong cryptography or are transmitted over an encrypted channel that uses strong cryptography.

Describe any additional software tests performed to support …

Added p. 84

Describe what the assessor observed in the documentation, evidence, and software test results that confirms whether the software relies upon third- party or execution environment features for securing sensitive data during transmission.

Identify the documentation and evidence that contains the software vendor’s guidance on the configuration and use of all third-party or execution-environment features to protect transmitted sensitive data.

If “yes,” describe what the assessor observed in the documentation, evidence, and software test results that confirms that all ingress and egress methods used to transmit sensitive data enforce secure versions of the TLS protocol with end-point authentication.

Describe what the assessor observed in the documentation, evidence, and software test results that confirms whether software methods that encrypt sensitive data for transmission allow for different types of cryptography or different levels of security to be used.

Describe what the assessor observed in the documentation, evidence, and software test results that confirms that all forms of …

Added p. 88

If “yes,” identify the documentation and evidence that contains the software vendor’s guidance on the configuration and use of third-party or platform- provided cryptographic services to protect sensitive data.

If “yes,” describe what the assessor observed in the documentation, evidence, and software test results that confirms private keys are not used to provide confidentiality protection for sensitive data.

If “no,” skip to 7.1.b.

Identify each of the unapproved algorithms or modes of operation used to protect critical assets.

For each unapproved algorithm or mode of operation used to protect critical assets, describe how each is used with approved algorithms to ensure a cryptographic key strength is equivalent to that of the approved algorithms.

Added p. 90

• Only documented cryptographic algorithms and modes are used in the software and are implemented correctly, and

• Protections are incorporated to prevent common cryptographic attacks such as the use of the software as a decryption oracle, brute-force or dictionary attacks against the input domain of the sensitive data, the re-use of security parameters such as IVs, or the re-encryption of multiple datasets using linearly applied key values (such as XOR’d key values in stream ciphers or one-time pads).

Describe what the assessor observed in the documentation, evidence, and software test results that confirms that the cryptographic algorithms and modes of operation in use are implemented correctly (that is, fit-for-purpose).

For each of the cryptographic algorithms or modes of operation that require a unique value per encryption operation or session, describe how the implementation of those algorithms and modes of operation protect against common cryptographic attacks.

Added p. 92

Identify each of the industry-accepted padding methods used by the software.

Identify each of the approved, collision- resistant hash algorithms and methods used by the software for the protection of sensitive data.

Added p. 94

Describe what the assessor observed in the documentation, evidence, and software test results that confirms that all cryptographic keys that provide security to critical assets or other security services to the software have a unique purpose.

Describe what the assessor observed in the documentation, evidence, and software test results that confirms that the integrity and confidentiality of all secret and private cryptographic keys managed by the software are protected when stored.

Added p. 98

Describe any additional software tests performed to support of this test requirement, including the tool(s)/method(s) used and the scope of each test.

Added p. 99

Describe what the assessor observed in the documentation, evidence, and software test results that suggests the software uses manually loaded public keys or uses public keys as root keys.

Describe what the assessor observed in the documentation, evidence, and software test results that confirms the keys are stored in a way that provides for dual control.

Describe what the assessor observed in the documentation, evidence, and software test results that confirms that all secret and private keys are managed in a way that ensures split knowledge over each key.

Describe any circumstances that make the absolute split knowledge of secret or private keys infeasible. Also describe the methods implemented to protect the secret and private keys in the absence of split knowledge.

Describe what the assessor observed in the documentation, evidence, and software test results that confirms the software vendor has defined crypto- periods for each of the cryptographic keys used for the protection …

Added p. 103

Describe what the assessor observed in the documentation and evidence that confirms that all vendor claims pertaining to the random number generation function(s) used do not exceed the scope of evaluation or approval of those random number generation functions.

Where problems are known, but have been mitigated by the software vendor, the assessor shall examine vendor evidence and test the software to confirm that the vulnerabilities have been sufficiently mitigated.

Describe what the assessor observed in the documentation, evidence, and software test results that confirms whether the software relies on third-party software, platforms, or libraries for random number generation.

Added p. 104

Describe how the documentation, evidence, and software test results confirm that there are no known vulnerabilities or other weaknesses present in the third-party software, platforms, or libraries used as part of the random number generation process that would compromise the software’s ability to generate sufficiently random values.

Describe any vulnerabilities that exist in the third-party software, platforms, or libraries that are used by the software as part of the random number generation process. Also describe the methods implemented in the software to mitigate those vulnerabilities.

Summarize how the software mitigates the interception or “hooking” of random number calls to/from the third-party software, platforms, or libraries providing random number generation functions.

Added p. 106

Describe what the assessor observed in the documentation, evidence, and software test results that indicate that the methods used to generate cryptographic keys and other key material have entropy that meets the minimum effective strength requirements of the cryptographic primitives and keys.

Describe what the assessor observed in the documentation, evidence, and software test results that confirms that the methods used to generate keys directly from a password/passphrase provide sufficient entropy, such that the total possible inputs are at least equal to that of the equivalent bit strength of the key being generated.

Added p. 108

• Clear and sufficient guidance is provided in the software vendor’s implementation guidance made available to stakeholders per Control Objective 12.1 that any passphrase used must be: o Randomly generated itself, using a valid and secure random process: an online random number generator must not be used for this purpose. o Never implemented by a single person, such that one person has an advantage in recovering the clear key value; violating the requirements for split knowledge.

Identify the documentation and evidence that contains the software vendor’s guidance on using passwords/passphrases that do not violate requirements for split knowledge.

Indicate whether any instances were found where third-party software, platforms, or libraries used as part of the random number generation process could not produce sufficient entropy (yes/no).

Identify the documentation and evidence that contains the software vendor’s guidance on securely configuring and using third-party software, platforms, or libraries that are part of the random number …

Added p. 112

Describe how the information identified in this test requirement is presented in the software activity logs or other activity tracking mechanism(s).

Describe what the assessor observed in any documentation, evidence, and software test results that confirms that sensitive data is not recorded in activity logs or in the output of other activity tracking mechanisms.

Describe what the assessor observed in the documentation, evidence, and software test results that confirms whether the software manages activity records.

Describe how the protection methods for ensuring the integrity of activity records mitigate the risk of unauthorized modification of the activity records.

Describe what the assessor observed in the documentation, evidence, and software test results that confirms whether the software uses or supports the use of external systems for storing or maintaining activity tracking data.

Identify the documentation and evidence that contains the software vendor’s guidance on how to securely configure the integration of the software with third- party or …

Added p. 119

If “yes,” describe what the assessor observed in the documentation, evidence, and software testing results that confirms that protection mechanisms are implemented to protect cryptographic primitives, and that those protections are appropriate for their intended purpose.

9.1.d Where stored values are used by any anomaly-detection methods, the assessor shall examine vendor evidence and test the software to confirm that these values are considered sensitive data and protected accordingly.

If “yes,” describe what the assessor observed in the documentation, evidence, and software test results that confirms that protection mechanisms are implemented to protect stored values, and that the protection mechanisms are appropriate for their intended purpose.

Describe what the assessor observed in the documentation, evidence, and results of the software tests that confirms whether configuration or other data set values can be modified by the software during execution.

For each of the integrity protections implemented, describe how the implementation allows for updates during execution, while …

Added p. 126

Describe the assessor’s rationale for why the software vendor’s security update release criteria are reasonable given the software’s intended purpose and function, and the critical assets maintained by the software.

Describe what the assessor observed in the documentation and evidence that confirms that the software vendor makes security updates available to stakeholders in accordance with its own defined security update release criteria and does not make exceptions on a regular basis.

If “yes,” for each instance identified describe the vendor’s justification for not providing security fixes, and why the assessor considers each exception reasonable given the risk posed by the continued existence of known vulnerabilities in the software.

Describe what the assessor observed in the documentation, evidence, and software test results that confirms that the software vendor’s methods for delivering software updates protect the integrity of the software and its code during transmission and installation (or implementation).

If “yes,” identify the documentation and evidence …

Added p. 141

Control Objective and Test Requirements Reporting Instructions Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) Control Objective B.1: Terminal Software Documentation The software architecture is documented and includes diagrams that describe all software components and services in use and how they interact.

B.1.1 The software vendor maintains documentation that describes all software components, interfaces, and services provided or used by the software.

In Place N/A Not in Place B.1.1 The assessor shall examine all relevant documentation and evidence necessary to confirm that the software vendor maintains documentation describing the software’s overall design and function including, but not limited to, the following:

• All third-party and open-source components, external services, and Application Programming Interfaces (APIs) used by the software.

• All User Interfaces (UI) and APIs provided or made accessible by the software.

Identify the documentation and evidence examined that identifies and describes all third-party and open-source components, external services, and Application Programming Interfaces …

Added p. 142

In Place N/A Not in Place B.1.2.a The assessor shall examine all relevant documentation and evidence necessary to confirm that the software vendor maintains documentation describing all sensitive data flows including, but not limited to, the following:

• All sensitive data stored, processed, or transmitted by the software.

• All locations where sensitive data is stored, including both temporary and persistent storage locations.

• How sensitive data is securely deleted from storage (both temporary and persistent) when no longer needed.

Identify the documentation and evidence examined that identifies and describes the sensitive data that is stored, processed, or transmitted by the software.

Added p. 142

Identify the documentation and evidence examined that describes how sensitive data is securely deleted from storage when no longer needed.

Added p. 143

• All inputs, outputs, and possible error conditions for each function that handles sensitive data.

• All cryptographic algorithms, modes of operation, and associated key management practices for all functions that employ cryptography for the protection of sensitive data.

Identify the documentation and evidence examined that identifies and describes all software functions that handle sensitive data.

Identify the documentation and evidence examined that identifies and describes all inputs and outputs for each software function that handles sensitive data.

Identify the documentation and evidence examined that identifies and describes all possible error conditions for each software function that handles sensitive data.

Identify the documentation and evidence examined that identifies and describes the cryptographic algorithms and modes of operation used and supported for each instance where cryptography is used to protect sensitive data.

Identify the documentation and evidence examined that identifies and describes how cryptographic keys are managed for each instance where cryptography is used to protect sensitive …

Added p. 144

In Place N/A Not in Place B.1.3 The assessor shall examine all relevant documentation and evidence necessary to confirm that the software vendor maintains documentation describing all configurable options provided or made available by the software that can impact the security of sensitive data including, but not limited to, the following:

• All configurable options that could allow access to sensitive data.

• All configurable options that could enable modification of any mechanisms used to protect sensitive data.

• All remote access features, functions, and parameters provided or made available by the software.

• All remote update features, functions, and parameters provided or made available by the software.

• The default settings for each configurable option.

Identify the documentation and evidence examined that identifies and describes all configurable options that enable access to sensitive data.

Identify the documentation and evidence examined that identifies and describes all configurable options that enable modification of mechanisms used to protect sensitive …

Added p. 145

B.2.1 The software is intended for deployment and operation on payment terminals (i.e., PCI-approved POI devices).

In Place N/A Not in Place B.2.1 The assessor shall examine all relevant software documentation and evidence necessary to determine the payment terminals upon which the software is to be deployed. For each of the payment terminals identified in the software documentation and included in the software assessment, the assessor shall examine the payment terminal’s device characteristics and compare them with the following characteristics specified in the PCI SSC’s List of Approved PTS Devices to confirm they match:

• PTS approval number

• Hardware version number

• Firmware version number(s) Identify the documentation and evidence examined that identifies the POI devices supported by the software.

Describe what the assessor observed in the documentation and evidence that confirms that the software is intended for deployment on PCI-approved POI devices.

Describe what the assessor observed in the documentation and evidence that confirms …

Added p. 146

In Place N/A Not in Place B.2.2.a The assessor shall examine all relevant software documentation and source code necessary to determine whether the software supports external communications.

Describe how and the extent to which the source code was examined to determine whether the software support supports external communications.

Describe what the assessor observed in the documentation, evidence, and source code that confirms whether the software supports external communications.

If “yes,” complete the reporting instructions for test requirements B.2.2.b through B.2.2.2.

Added p. 147

Identify the external communication methods included in the payment terminal’s PTS POI device evaluation.

Indicate whether there are any discrepancies between the list of external communication methods used by the software and the list of PCI-approved external communication methods provided by the payment terminal. (yes/no).

If “no,” skip to B.2.2.c.

Describe each of the discrepancies between the external communication methods supported by the software and those included in the payment terminal’s PTS POI device evaluation.

For each of the noted discrepancies, describe the assessor’s rationale for why the discrepancy does not violate the control objective.

Added p. 148

Describe what the assessor observed in the documentation, evidence, and source code that confirms the software only uses the PCI-approved external communication methods included in the payment terminal’s PTS POI device evaluation and does not implement its own external communication methods (that is, its own IP stack).

B.2.2.1 Where the software relies on the Open Protocols features of the payment terminal, the software is developed in accordance with the payment terminal vendor’s security guidance/policy.

In Place N/A Not in Place B.2.2.1 The assessor shall examine all relevant payment terminal documentation

•including the payment terminal vendor’s security guidance/policy

•and all relevant software vendor process documentation and software design documentation to confirm that the software is developed in accordance with the payment terminal vendor’s security guidance/policy.

Describe what the assessor observed in the documentation and evidence that confirms whether the software relies on the Open Protocols features of the payment terminal.

Indicate whether the software relies on the …

Added p. 149

B.2.2.2 The software does not circumvent, bypass, or add additional services or protocols to the Open Protocols of the payment terminal as approved and documented in the payment terminal vendor’s security guidance/policy. This includes the use of link layer protocols, IP protocols, security protocols, and IP services.

In Place N/A Not in Place B.2.2.2 The assessor shall examine all relevant software documentation and source code to confirm that the software does not circumvent, bypass, or add additional services or protocols to the Open Protocols of the payment terminal as approved and documented in the payment terminal vendor’s security guidance/policy. This includes the use of:

• Link Layer protocols

• IP Services Identify the documentation and evidence examined in support of this test requirement.

Describe what the assessor observed in the documentation, evidence, and source code that confirms that the software does not circumvent, bypass, or add additional services or protocols to the Open Protocols …

Added p. 150

In Place N/A Not in Place B.2.3.a The assessor shall examine all relevant software documentation and source code necessary to determine whether the software facilitates encryption of sensitive data. Where the software does provide such a function, the assessor shall confirm the software does not bypass or render ineffective any encryption methods or account data security methods implemented by the payment terminal as follows:

Describe what the assessor observed in the documentation, evidence, and source code that determines whether the software supports the encryption of sensitive data.

Added p. 150

If “yes,” complete the reporting instructions for test requirements B.2.3.b through B.2.3.d.

B.2.3.b The assessor shall examine all relevant payment terminal documentation

•including payment terminal vendor security guidance/policy

•necessary to determine which encryption methods are provided by the payment terminal.

Identify each of the encryption methods provided by the payment terminal.

Added p. 151

Describe what the assessor observed in the documentation, evidence, and source code that confirms that the software does not bypass or render ineffective any encryption methods provided by the payment terminal.

B.2.3.d Where the software facilitates encryption of sensitive data, but the payment terminal is not required to provide approved encryption methods (per the PCI PTS POI Standard), the assessor shall examine all relevant software documentation and source code necessary to confirm that the encryption methods used or implemented by the software for encrypting sensitive data provide “strong cryptography” and are implemented in accordance with Control Objectives 7.1 and 7.2.

Added p. 151

Describe what the assessor observed in the documentation and evidence that confirms whether the payment terminal is required to provide approved encryption methods as part of its PCI PTS POI device evaluation.

Indicate whether the payment terminal is required to provide approved encryption methods as part of its PCI PTS POI device evaluation (yes/no).

If “yes,” skip to B.2.4.

If “no,” complete the remaining reporting instructions for this test requirement.

Added p. 152

B.2.4 The software uses only the random number generation function(s) included in the payment terminal’s PTS device evaluation for all cryptographic operations involving sensitive data or sensitive functions where random values are required and does not implement its own random number generation function(s).

In Place N/A Not in Place B.2.4.a The assessor shall examine all relevant software documentation and source code necessary to determine whether the software requires random values to be generated for any cryptographic operations involving sensitive data or sensitive functions.

Describe what the assessor observed in the documentation, evidence, and source code examined that confirms whether the software requires random number values for cryptographic operations involving sensitive data or sensitive functions.

Indicate whether the software requires random number values for cryptographic operations involving sensitive data or sensitive functions (yes/no).

If “yes,” complete the reporting instructions for test requirements B.2.4.b through B.2.4.c.

If “no,” skip to B.2.4.c.

Added p. 153

Indicate whether there are any discrepancies between the list of random number generation functions used by the software and the list of PCI-approved random number generation functions provided by the payment terminal (yes/no).

Identify the discrepancies found between the random number functions used by the software and those included in the payment terminal’s PTS POI device evaluation.

For each of the noted discrepancies, describe the assessor’s rationale for why the discrepancy does not violate the parent control objective.

Added p. 154

Describe what the assessor observed in the documentation, evidence, and source code that confirms that the software only uses the PCI-approved random number generation functions included in the payment terminal’s PCI PTS POI device evaluation and does not implement its own random number generation functions.

Added p. 155

In Place N/A Not in Place B.2.5.a The assessor shall examine all relevant software documentation and source code necessary to determine all logical interfaces of the software, including:

• All logical interfaces and the purpose and function of each.

• The logical interfaces intended for sharing clear-text account data, such as those used to pass clear- text account data back to the approved firmware of the payment terminal.

• The logical interfaces not intended for sharing of clear-text account data, such as those for communication with other software.

Identify all discrepancies found between the logical interfaces identified through documentation and evidence reviews and the logical interfaces identified through source code reviews.

For each of the noted discrepancies, describe the software vendor’s justification for why the discrepancy exists and the assessor’s rationale for why the discrepancy is considered acceptable.

Added p. 156

Describe what the assessor observed in the documentation, evidence, and source code in B.2.5.a that indicates that the software does not support sharing of clear-text account data directly with other software through its own logical interfaces.

B.2.5.c The assessor shall install and configure the software in accordance with the software vendor’s implementation guidance required in Control Objectives 12.1 and B.5.1. Using an appropriate “test platform” and suitable forensic tools and/or methods (commercial tools, scripts, etc.) the assessor shall test the software using all software functions that handle account data to confirm that the software does not facilitate the sharing of clear-text account data directly with other software through its own logical interfaces.

Describe each of the tests performed in support of this test requirement, including the tool(s) or method(s) used and the scope of each test.

Describe what the assessor observed in the software testing results that confirms that the software does not …

Added p. 157

In Place N/A Not in Place B.2.6.a The assessor shall examine all relevant software documentation and source code necessary to determine whether and how the software connects to and/or uses any shared resources provided by the payment terminal, and to confirm that:

• The software vendor’s implementation guidance required in Control Objectives 12.1 and B.5.1 includes detailed instructions for how to configure the software to ensure secure integration with shared resources.

• The software vendor’s implementation guidance for secure integration with such shared resources is in accordance with the payment terminal vendor’s security guidance/policy.

Describe what the assessor observed in the documentation, evidence, and source code that confirms whether the software connects to and/or uses any shared resources provided by the payment terminal.

If “yes,” complete the remaining reporting instructions for this test requirement and test requirement B.2.6.b.

Describe what the assessor observed in the documentation and evidence that confirms that the software vendor provides …

Added p. 158

B.2.6.b The assessor shall install and configure the software in accordance with the software vendor’s implementation guidance required in Control Objectives 12.1 and B.5.1. Using an appropriate “test platform” and suitable forensic tools and/or methods (commercial tools, scripts, etc.) the assessor shall test the software using all software functions that use or integrate shared resources to confirm that any connections to or use of shared resources are handled securely.

Describe what the assessor observed in the documentation, evidence, and software test results that confirms that the software’s connection to and use of any shared resources provided by the payment terminal are handled securely.

B.2.7 The software does not bypass or render ineffective any application segregation enforced by the payment terminal.

In Place N/A Not in Place B.2.7.a The assessor shall examine all relevant payment terminal documentation

•including the payment terminal vendor’s security guidance/policy

•necessary to determine whether and how application segregation is enforced by the …

Added p. 159

Describe what the assessor observed in documentation, evidence, and source code that confirms that the software does not include functions that would enable it to bypass or defeat any device-level application segregation controls provided by an underlying payment terminal.

B.2.8 All software files are cryptographically signed to facilitate cryptographic authentication of the software files by the payment terminal firmware.

In Place N/A Not in Place B.2.8.a The assessor shall examine the software vendor’s implementation guidance required in Control Objectives 12.1 and B.5.1 to confirm it includes detailed instructions for how to cryptographically sign the software files in a manner that facilitates the cryptographic authentication of all such files by the payment terminal.

Describe what the assessor observed in the documentation and evidence that confirms that the software vendor provides guidance to stakeholders on how to cryptographically sign software files in a manner that supports cryptographic authentication of all such files by an underlying …

Added p. 160

Identify any additional documentation and evidence examined in support this test requirement.

Describe what the assessor observed in the documentation, evidence, and software test results that confirms that all software files are cryptographically signed in a manner that supports the cryptographic authentication of all software files by an underlying payment terminal’s firmware.

B.2.8.c Where the software supports the loading of files outside of the base software package(s), the assessor shall determine whether each of those files is cryptographically signed in a manner that facilitates the cryptographic authentication of those files by the payment terminal. For any files that cannot be cryptographically signed, the assessor shall justify why the inability to cryptographically sign each such files does not adversely affect the security of the software or the underlying payment terminal.

Describe how and the extent to which source code was examined to support this test requirement.

Describe what the assessor observed in the documentation, evidence, …

Added p. 161

Where files were found that were not or could not be cryptographically signed, describe the assessor’s rationale for why the inability to cryptographically sign and authenticate such files does not adversely affect the security of the software or an underlying payment terminal.

B.2.8.d The assessor shall examine all relevant software documentation and source code necessary to determine whether and how the software supports EMV® payment transactions. Where EMV payment transactions are supported by the software, the assessor shall install and configure the software in accordance with the software vendor’s implementation guidance required in Control Objectives 12.1 and B.5.1. Using an appropriate “test platform” and suitable forensic tools and/or methods (commercial tools, scripts, etc.) the assessor shall confirm that all EMV Certification Authority Public Keys are cryptographically signed in a manner that facilitates the cryptographic authentication of those files by the payment terminal.

Describe what the assessor observed in the documentation, evidence, and …

Added p. 162

B.2.9 The integrity of software prompt files is protected in accordance with Control Objective B.2.8. In Place N/A Not in Place B.2.9.a The assessor shall examine all relevant software documentation and source code necessary to determine whether the software supports the use of data entry prompts and/or prompt files. Where the software supports such features, the assessor shall confirm the software protects the integrity of those prompts as defined in Test Requirements B.2.9.b through B.2.9.c.

Describe what the assessor observed in the documentation, evidence, and source code that confirms whether the software supports the use of data entry prompts and/or prompt files.

Indicate whether the software supports the use of data entry prompts and/or prompt files (yes/no).

If “yes,” complete the remaining reporting instructions for test requirements B.2.9.b through B.2.9.c.

Added p. 163

Describe what the assessor observed in the documentation and evidence that confirms that the software vendor provides guidance to stakeholders on how to cryptographically sign all prompt files in a manner that supports the cryptographic authentication of those files in accordance with Control Objective B.2.8.

B.2.9.c The assessor shall install and configure the software in accordance with the software vendor’s implementation guidance required in Control Objectives 12.1 and B.5.1. Using an appropriate “test platform” and suitable forensic tools and/or methods (commercial tools, scripts, etc.) the assessor shall confirm that all prompt files are cryptographically signed in a manner that facilitates the cryptographic authentication of those files by the payment terminal in accordance with B.2.8.

Identify any documentation and evidence examined in support of this test requirement.

Describe what the assessor observed in any documentation, evidence, and software test results that confirms that all prompt files are cryptographically signed in a manner that supports …

Added p. 164

B.3.1 The software validates all use and other external inputs. Note: Control Objectives B.3.1 through B.3.3 are extensions of Control Objective 4.2. Validation of these control objectives should be performed at the same time.

In Place N/A Not in Place B.3.1.a The assessor shall examine all relevant software documentation and source code necessary to identify all external inputs to the software. For each user or other external input, the assessor shall examine all relevant software documentation and source code to confirm that inputs conform to a list of expected characteristics and that all input that does not conform to expected characteristics is rejected by the software or otherwise handled securely.

Describe what the assessor observed in the documentation, evidence, and source code that confirms that all software inputs are checked upon data entry to determine whether the data conforms to a set of expected characteristics.

Describe what the assessor observed in the documentation, …

Added p. 165

Describe what the assessor observed in the software testing results that confirms that all software inputs are validated upon data entry.

Describe what the assessor observed in the software testing results that confirms all invalid data or data that does not conform to expected characteristics are either rejected or handled securely.

B.3.1.1 All string values are validated by the software.

In Place N/A Not in Place B.3.1.1.a The assessor shall examine all relevant software documentation and source code necessary to identify all terminal software functions where string values are passed as inputs to confirm that all strings are checked for text or data that can be erroneously or maliciously interpreted as a command.

Describe how the assessor ensured that all software inputs where input data is passed to the software as a string value were identified and checked for compliance with the parent control objective.

Added p. 166

Describe what the assessor observed in the documentation, evidence, and source code that confirms that all such values are either rejected or handled securely.

Where the software handles such input data rather than rejecting it, describe each of the methods implemented by the software to ensure such input data is handled safely.

B.3.1.1.b The assessor shall install and configure the software in accordance with the software vendor’s implementation guidance required in Control Objectives 12.1 and B.5.1. Using an appropriate “test platform” and suitable forensic tools and/or methods (commercial tools, scripts, etc.), the assessor shall test the software by attempting to supply each of the identified functions with data that includes commands to confirm that the software either rejects such inputs or otherwise handles such inputs securely.

Describe what the assessor observed in the software testing results that confirms that all input data containing commands is either rejected or handled safely and securely.

Added p. 167

In Place N/A Not in Place B.3.1.2.a The assessor shall examine all relevant software documentation and source code necessary to identify all software functions that handle buffers and process data supplied by external inputs. For each of the noted functions, the assessor shall confirm that each of the identified functions:

• Uses only unsigned variables to define buffer sizes.

• Conducts checks that confirm that buffers are sized appropriately for the data they are intended to handle, including consideration for underflows and overflows.

• Rejects or otherwise securely handles any inputs that violate buffer size or other memory allocation thresholds.

Describe how the assessor ensured that all software inputs that handle buffers and process externally provided data were identified.

Describe what the assessor observed in the documentation, evidence, and source code that confirms that only unsigned variables are used to define buffer sizes.

Describe what the assessor observed in the documentation, evidence, and source code that …

Added p. 168

B.3.1.2.b The assessor shall install and configure the software in accordance with the software vendor’s implementation guidance required in Control Objectives 12.1 and B.5.1. Using an appropriate “test platform” and suitable forensic tools and/or methods (commercial tools, scripts, etc.) the assessor shall test the software by attempting to supply each noted function with inputs that violate buffer size thresholds to confirm that the software either rejects or securely handles all such attempts.

Describe what the assessor observed in the software testing results that confirms that all input data that violates buffer size or other memory allocation thresholds is rejected or handled securely.

B.3.2 Return values are checked, and error conditions are handled securely.

In Place N/A Not in Place B.3.2.a The assessor shall examine all relevant software documentation and source code necessary to identify all software functions that handle the sensitive data predefined in Control Objective 1.2. For each of the noted software …

Added p. 169

B.3.3 Race conditions are avoided.

In Place N/A Not in Place B.3.3.a The assessor shall examine all relevant software documentation and source code necessary to identify all software functions that rely on synchronous processing. For each of the noted functions, the assessor shall confirm that protection mechanisms have been implemented in the software to mitigate race conditions.

Describe what the assessor observed in the documentation, evidence, and source code that confirms protection mechanisms are implemented in the software to mitigate race conditions.

Added p. 170

Describe what the assessor observed in the software testing results that confirms that the software is resistant to race conditions.

Added p. 171

B.4.1 A documented process is maintained and followed for testing software for vulnerabilities prior to each update or release.

Note: This control objective is an extension of Control Objective 10.2. Validation of these control objectives should be performed at the same time.

In Place N/A Not in Place B.4.1.a The assessor shall examine all relevant software documentation and evidence necessary to confirm that the software vendor maintains a documented process in accordance with Control Objective 10.2 for testing the software for vulnerabilities prior to each update or release, and that the documented process includes detailed descriptions of how the vendor tests for the following:

• The presence or use of any unnecessary ports and protocols.

• The unintended storage, transmission, or output of any clear-text account data.

• The presence of any default user accounts with default or static access credentials.

• The presence of any hard-coded authentication credentials in code or in configuration files.

• The …

Added p. 172

Describe when and the frequency with which the software is tested for the presence of any faulty or ineffective software security controls.

B.4.1.b The assessor shall examine all relevant documentation and evidence necessary (such as software testing artifacts, etc.) to confirm that the software is tested for vulnerabilities prior to each release and that the testing covers the following:

Describe what the assessor observed in the documentation and evidence that confirms that the software is routinely tested for the presence or use of unnecessary ports or protocols.

Describe what the assessor observed in the documentation and evidence that confirms that the software is routinely tested for the unintended storage, transmission, or output of clear-text account data.

Describe what the assessor observed in the documentation and evidence that confirms that the software is routinely tested for the presence of default user accounts with default or static access credentials.

Describe what the assessor observed in the documentation …

Added p. 173

Describe what the assessor observed in the documentation and evidence that confirms that the software is routinely tested for the presence of faulty or ineffective software security controls.

Added p. 174

B.5.1 The software vendor provides implementation guidance on how to implement and operate the software securely for the payment terminals on which it is to be deployed. Note: This control objective is an extension of Control Objective 12.1. Validation of these control objectives should be performed at the same time.

In Place N/A Not in Place B.5.1 The assessor shall examine all relevant software documentation and evidence necessary to confirm that the software vendor provides detailed implementation guidance to stakeholders in accordance with Control Objective 12.1 on how to securely implement and operate the software for all applicable payment terminals.

Describe what the assessor observed in the documentation and evidence that confirms that the software vendor provides detailed guidance to stakeholders on how to securely implement and operate the software for all payment terminals on which the software is to be deployed.

Describe what the assessor observed in the documentation and evidence that …

Added p. 175

In Place N/A Not in Place B.5.1.2 The assessor shall examine the software vendor implementation guidance to confirm it includes detailed instructions on how to securely configure the software to use the security features and functions of the payment terminal where applicable.

Describe what the assessor observed in the documentation and evidence that indicates that the software vendor’s guidance covers all payment terminal security features and functions used by the software.

Describe what the assessor observed in the documentation and evidence that demonstrates that the software vendor’s guidance covers the secure configuration and use of security features and functions for all payment terminals upon which the software is to be deployed.

B.5.1.3 Implementation guidance includes detailed instructions for how to configure the software to securely integrate or use any shared resources provided by the payment terminal.

In Place N/A Not in Place B.5.1.3 The assessor shall examine the software vendor implementation guidance to confirm …

Added p. 176

B.5.1.4 Implementation guidance includes detailed instructions on how to cryptographically sign the software files in a manner that facilitates the cryptographic authentication of all such files by the payment terminal.

In Place N/A Not in Place B.5.1.4 The assessor shall examine the software vendor implementation guidance to confirm it includes detailed instructions on how to cryptographically sign the software files in a manner that facilitates the cryptographic authentication of all such files by the payment terminal in accordance with Control Objective B.2.8.

Describe what the assessor observed in the documentation and evidence that indicates that the software vendor’s guidance covers cryptographic signing for all software files.

Describe what the assessor observed in the documentation and evidence that demonstrates that the software vendor’s guidance covers cryptographic signing for all payment terminals upon which the software is to be deployed.

B.5.1.5 Implementation guidance includes instructions for stakeholders to cryptographically sign all prompt files.

In Place N/A Not …

Added p. 177

In Place N/A Not in Place B.5.2 The assessor shall examine the payment terminal vendor’s security guidance/policy and the software implementation guidance required in Control Objective B.5.1 to confirm that the software implementation guidance aligns with the payment terminal vendor’s security guidance/policy.

Describe what the assessor observed in the documentation and evidence that demonstrates the software vendor’s guidance for securely configuring the underlying payment terminal aligns with the payment terminal vendor’s security guidance for each payment terminal upon which the software is to be deployed.

Removed p. 4

• Secure Software Report on Validation Reporting Template (which will subsequently be referred to as the “Secure Software ROV Reporting Template”) is for use with the PCI Software Security Framework

Tables have been included in this template to facilitate the reporting process for certain lists and other information as appropriate. The tables in this template may be modified to increase or decrease the number of rows or to change column width. Additional appendices may be added if the assessor feels there is relevant information to be included that is not addressed by the current format. However, the assessor must not remove any details from the tables provided in this document. Personalization, such as the addition of company logos, is acceptable but should be limited to the title page and the headers for the remainder of the document.

Removed p. 4

• Secure Software Standard Program Guide

• Secure Software Attestation of Validation (AOV)

Modified p. 4 → 5

• Secure Software Requirements and Assessment Procedures ~~(“PCI~~ Secure Software ~~Standard”)~~ and is the mandatory template for Secure Software Assessors completing a Secure Software Assessment. The Secure Software ROV Reporting Template provides reporting instructions and a reporting template for Secure Software ~~Assessors to use. Using this~~ template assures a consistent level of reporting against the PCI Secure Software Standard ~~amongst~~ assessors.

• Secure Software Requirements and Assessment Procedures (PCI Secure Software Standard) Version 1.1 and is the mandatory template for Secure Software Assessors completing a Secure Software Assessment. The Secure Software ROV Reporting Template provides reporting instructions and a reporting template for Secure Software Assessors. This template assures a consistent level of reporting against the PCI Secure Software Standard for all assessors.

Modified p. 4 → 5

~~Note: Use of this~~ Reporting Template is mandatory for all Secure Software Assessment report submissions to PCI SSC.

This Reporting Template is mandatory for all Secure Software Assessment report submissions to PCI SSC.

Modified p. 4 → 5

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 → 5

A Secure Software 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 Software Report on Validation (ROV) is effectively a summary of evidence derived from the assessor’s work papers to describe how the assessor …

A Secure Software Assessment involves thorough testing and assessment activities from which the assessor generates 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 Software Report on Validation (ROV) is effectively a summary of evidence derived from the assessor’s work papers to describe how the assessor performed …

Modified p. 4 → 5

~~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.

Use this template in conjunction with the appropriate versions of the following PCI Software Security Framework documents, which are available on the PCI SSC website at https://www.pcisecuritystandards.org.

Modified p. 5 → 6

A. Additional Information Worksheet B. Testing Environment Configuration for Secure Software Assessments All numbered sections must be thoroughly and accurately completed. The Secure Software ROV Reporting Template also contains instructions to help ensure that Secure Software Assessors supply all required information for each section. All responses should be entered in the applicable location or table provided in the template. Responses should be specific, but efficient. Details provided should focus on the quality of detail, rather than lengthy, repeated text. Copying …

Appendix A, Additional Information Worksheet Appendix B, Testing Environment Configuration for Secure Software Assessments All numbered sections must be thoroughly and accurately completed. The Secure Software ROV Reporting Template also contains instructions to help ensure that Secure Software Assessors supply all required information for each section. All responses should be entered in the applicable location or table provided in the template. Responses should be specific, but efficient. Details provided should focus on the quality of detail, rather than lengthy, repeated …

Modified p. 5 → 6

Documenting the Assessment Findings and Observations Within the ~~“Findings~~ and ~~Observations”~~ section of the Secure Software ROV Reporting Template is where the detailed results of the software assessment are documented. In this section, an effort was made to efficiently use space and provide a snapshot view of assessment results ~~(“Summary~~ of Assessment ~~Results”)~~ ahead of the detailed reporting that is to be specified in the “Reporting Details: Assessor’s Response” column. An example layout of the ~~“Findings~~ and ~~Observations”~~ section is …

Documenting the Assessment Findings and Observations Within the Findings and Observations section of the Secure Software ROV Reporting Template is where the detailed results of the software assessment are documented. In this section, an effort was made to efficiently use space and provide a snapshot view of assessment results (Summary of Assessment Results) ahead of the detailed reporting that is to be specified in the “Reporting Details: Assessor’s Response” column. An example layout of the Findings and Observations section is …

Modified p. 6 → 7

~~Table 1: Findings and Observations Control Objectives and Test Requirements Reporting Instructions Reporting Details:~~ Assessor’s ~~Response~~ Summary of Assessment Findings (check one) 1.1 Detailed Control Objective Summary In Place N/A Not in Place ~~1.1~~ Test Requirement Reporting Instruction Reporting Instruction For the Summary of Assessment Findings, there are three results possible•In Place, Not Applicable (N/A), and Not in Place. Only one selection is to be made for each control objective. Table 2 provides a helpful representation when considering which selection …

Assessor’s Summary of Assessment Findings (check one) 1.1 Detailed Control Objective Summary In Place N/A Not in Place 1.1.a Test Requirement Reporting Instruction Reporting Instruction For the Summary of Assessment Findings, there are three results possible•In Place, Not Applicable (N/A), and Not in Place. Only one selection is to be made for each control objective. Table 2 provides a helpful representation when considering which selection to make. Reporting details and results should be consistent throughout the ROV, as well as …

Modified p. 6 → 7

Table 2: Selecting the Appropriate Validation Result Response When to use this response:

Table 2. Selecting the Appropriate Validation Result Response When to use this response:

Modified p. 6 → 7

(Not Applicable) The control objective does not apply to the organization or their software development practices. All “N/A” responses require reporting on the testing performed to confirm the “N/A” status. Note that a “N/A” response still requires a detailed description explaining how it was determined that the control objective does not apply.

N/A (Not Applicable) The control objective does not apply to the organization or their software development practices. All “N/A” responses require reporting on the testing performed to confirm the “N/A” status. Note that a “N/A” response still requires a detailed description explaining how it was determined that the control objective does not apply.

Modified p. 7 → 8

Table 3: Reporting Instruction Terms and Response Formats Reporting Instruction ~~Term~~ Example Usage Description of Response Describe Describe each of the software tests performed to identify the transaction types and card data elements supported by the software.

Table 3. Reporting Instruction Terms and Response Formats Reporting Instruction Example Usage Description of Response Describe Describe each of the software tests performed to identify the transaction types and card data elements supported by the software.

Modified p. 7 → 8

The response would include a detailed description of the item or activity in question

• for example, details of how evidence examined or individuals interviewed demonstrate a control objective was met, or how the assessor concluded an implemented security control is fit-for-purpose. The response should be of sufficient detail to provide the reader with a comprehensive understanding of the item or activity being described.

The response would include a detailed description of the item or activity in question

• for example, details of how evidence examined and/or individuals interviewed demonstrate a control objective was met, or how the assessor concluded an implemented security control is fit-for-purpose. The response should be of sufficient detail to provide the reader with a comprehensive understanding of the item or activity being described.

Modified p. 7 → 8

Identify Identify the ~~vendor~~ evidence examined that outlines all configuration options provided by the software.

Identify Identify the documentation and evidence examined that outlines all configuration options provided by the software.

Modified p. 7 → 8

The response would be a brief overview or descriptive list of the applicable items

• for example: the titles of documents that were ~~examined,~~ a list of vulnerabilities that were tested, or the names and job titles of individuals who were interviewed.

The response would be a brief overview or descriptive list of the applicable items

• for example: the titles of documents that were examined or generated by the assessor, a list of vulnerabilities that were tested, or the names and job titles of individuals who were interviewed.

Modified p. 7 → 8

Note: The applicability of some reporting instructions may be dependent on the response of a previous reporting instruction. For example, a response of “yes” to a question about a Secure Software control may result in further details being requested about that ~~particular~~ control. If applicable, the reporting instruction will direct the assessor to a subsequent instruction based on the yes/no answer.

Note: The applicability of some reporting instructions may be dependent on the response of a previous reporting instruction. For example, a response of “yes” to a question about a Secure Software control may result in further details being requested about that control. If applicable, the reporting instruction will direct the assessor to a subsequent instruction based on the yes/no answer.

Modified p. 7 → 8

The response would provide a high-level overview of a security control, process, ~~mechanism~~ or tool that is implemented or used by the vendor to satisfy a control objective. For example, summarizing a security control or protection mechanism would include information about what is implemented, what it does, and how it meets its purpose.

The response would provide a high-level overview of a security control, process, mechanism, or tool that is implemented or used by the vendor to satisfy a control objective. For example, summarizing a security control or protection mechanism would include information about what is implemented, what it does, and how it meets its purpose.

Modified p. 8 → 9

• Ensure the response covers all applicable systems, processes, and components including those provided by ~~third-parties.~~

• Ensure the response covers all applicable systems, processes, and components including those provided by third parties.

Removed p. 9

• Appendix A: Additional Information Worksheet

Modified p. 9 → 10

• Appendix B: Testing Environment Configuration for Secure Software Assessments Appendix A is optional and may be used to add extra information to support the assessment findings if the information is too large to fit in the Reporting Details: Assessor Response column within the Findings and Observations section. Examples of information that may be added in Appendix A include diagrams, flowcharts, or tables that support the Secure Software Assessor’s findings. Any information recorded in Appendix A should reference back to …

Appendix A, Additional Information Worksheet Appendix B, Testing Environment Configuration for Secure Software Assessments Appendix A is optional and may be used to add extra information to support the assessment findings if the information is too large to fit in the Reporting Details: Assessor Response column within the Findings and Observations section. Examples of information that may be added in Appendix A include diagrams, flowcharts, or tables that support the Secure Software Assessor’s findings. Any information recorded in Appendix A …

Modified p. 9 → 10

Appendix B is mandatory and must be used to confirm that the environment used by the assessor to conduct the Secure Software Assessment was configured in accordance with Section ~~5.5.1~~ of the Secure Software ~~Standard~~ Program Guide. This confirmation must be submitted to PCI SSC along with the completed Report on Validation (ROV).

Appendix B is mandatory and must be used to confirm that the environment used by the assessor to conduct the Secure Software Assessment was configured in accordance with Section 4.5.1 of the Secure Software Program Guide. This confirmation must be submitted to PCI SSC along with the completed Report on Validation (ROV).

Modified p. 12 → 13

Is the software already listed on the PCI SSC List of Validated Payment Software? Yes No If ~~“Yes,”~~ provide the Validated Payment Software name and PCI Identifier:

Is the software already listed on the PCI SSC List of Validated Payment Software? Yes No If “yes,” provide the Validated Payment Software name and PCI Identifier:

Modified p. 12 → 13

~~Product category~~ for this software (Please refer to Section ~~A.3~~ of the Secure Software ~~Standard~~ Program Guide for a detailed explanation of ~~product categories):~~

Payment Software Type for this software (Please refer to Section A.2 of the Secure Software Program Guide for a detailed explanation of software types):

Modified p. 12 → 13

Describe how the software is sold, distributed, or licensed to ~~third-parties~~ (for example, licensed as software-as-a-service, stand-alone application, etc.):

Describe how the software is sold, distributed, or licensed to third parties (for example, licensed as software-as-a-service, stand-alone application, etc.):

Modified p. 12 → 13

Describe how the software is designed (for example, as a standalone application, as a component or library, or as part of a suite of applications) Describe a typical implementation of the software (for example, how it is configured in the execution ~~environment,~~ other systems or ~~components it typically interacts with, etc.)~~

Describe how the software is designed (for example, as a standalone application, as a component or library, or as part of a suite of applications) Describe a typical implementation of the software (for example, how it is configured in the execution environment or how it typically interacts with other systems or components).

Modified p. 13 → 14

Device Make / Manufacturer Device Model Name / Number Device Version (wildcards permitted) Device Description (e.g., device type, function, etc.) Example: Acme, Inc. Acme POS v1.x Integrated POS, secure card reader and pin-entry ~~device~~

Device Make / Manufacturer Device Model Name / Number Device Version (wildcards permitted) Device Description (e.g., device type, function, etc.) Example: Acme, Inc. Acme POS v1.x Integrated POS, secure card reader and pin-entry device.

Modified p. 14 → 15

Software Vendor / Owner Software Name Software Version (wildcards permitted) Software Description (e.g., type, function, etc.) Example: Acme, Inc. Acme E-commerce Server v2.x Web/application server 2.5 Other Required Software Components Does the assessed payment software rely on any other third-party or proprietary software, ~~APIs~~ or components to provide its intended functionality? If “yes,” identify and list all software, APIs, and components the assessed payment software relies upon to provide the full scope of its intended functionality:

Software Vendor / Owner Software Name Software Version (wildcards permitted) Software Description (e.g., type, function, etc.) Example: Acme, Inc. Acme E-commerce Server v2.x Web/application server 2.5 Other Required Software Components Does the assessed payment software rely on any other third-party or proprietary software, APIs, or components to provide its intended functionality? If “yes,” identify and list all software, APIs, and components the assessed payment software relies upon to provide the full scope of its intended functionality:

Modified p. 14 → 15

Software Vendor / Owner Software Name Software Version (wildcards permitted) Software Description (e.g., type, function, etc.) Example: Acme, Inc. Acme Crypto Library v3.x Suite of cryptographic libraries used for authentication and data ~~protection~~

Software Vendor / Owner Software Name Software Version (wildcards permitted) Software Description (e.g., type, function, etc.) Example: Acme, Inc. Acme Crypto Library v3.x Suite of cryptographic libraries used for authentication and data protection.

Modified p. 15 → 16

Note: Additional rows may be added to accommodate additional sensitive data types. Refer to the Software Security Framework

• Glossary of Terms, Abbreviations, and Acronyms for more information on how Sensitive Data ~~are~~ defined.

Note: Additional rows may be added to accommodate additional sensitive data types. Refer to the Software Security Framework

• Glossary of Terms, Abbreviations, and Acronyms for more information on how Sensitive Data is defined.

Modified p. 15 → 16

Sensitive Data Type (e.g., Account Data, authentication credentials, etc.) Description of Sensitive Data Elements (e.g., PAN/SAD, username/password, etc.) Summary of How the Sensitive Data is Handled (e.g., stored, processed, transmitted, etc.) Summary of How the Sensitive Data is Protected (e.g., encrypted during transmission, hashed during storage, etc.) 2.7 Overview of Sensitive Functions Provided Identify the sensitive functions provided by the software and describe how each is protected:

Sensitive Data Store (file [name], table [name], etc.) Sensitive Data Type (e.g., Account Data, authentication credentials, etc.) Description of Sensitive Data Elements (e.g., PAN/SAD, username/password, etc.) Summary of How the Sensitive Data is Handled (e.g., stored, processed, transmitted, etc.) Summary of How the Sensitive Data is Protected (e.g., encrypted during transmission, hashed during storage, etc.) 2.7 Overview of Sensitive Functions Provided Identify the sensitive functions provided by the software and describe how each is protected:

Modified p. 15 → 16

Sensitive Function Type (e.g., user authentication, data encryption, encryption key management, etc.) Associated Sensitive Data Types (e.g., account data, authentication credentials, etc.) Summary of How Sensitive Functions are Protected ~~(e.g.~~ access control mechanisms, integrity checks, etc.)

Sensitive Function Type (e.g., user authentication, data encryption, encryption key management, etc.) Associated Sensitive Data Types (e.g., account data, authentication credentials, etc.) Summary of How Sensitive Functions are Protected (e.g., access control mechanisms, integrity checks, etc.)

Modified p. 16 → 17

Sensitive Resource Name (e.g., LDAP, libcrypto, keychain, etc.) Associated Sensitive Function (user authentication, data encryption, encryption key management, etc.) Source / Provider ~~(Microsoft Active Directory, OpenSSL, iOS,~~ etc.) Summary of How Interactions are Secured (e.g., mutual authentication, access control, obfuscation, etc.) 2.9 Sensitive Data Flows

Sensitive Resource Name (e.g., LDAP, libcrypto, keychain, etc.) Associated Sensitive Function (user authentication, data encryption, encryption key management, etc.) Source / Provider (The entity that maintains the code e.g., Microsoft, Verifone, Ingenico, etc.) Summary of How Interactions are Secured (e.g., mutual authentication, access control, obfuscation, etc.) 2.9 Sensitive Data Flows

Modified p. 16 → 17

• For each data flow, identify the following: o How and where sensitive data is stored, processed and/or transmitted o The specific types and details of the sensitive data involved (e.g., full track, PAN, PIN, expiry date, user IDs, passwords, etc.) o All components involved in the storage, ~~processing~~ or transmission of sensitive data o All sensitive functions and resources associated with the sensitive data flow

• For each data flow, identify the following: o How and where sensitive data is stored, processed and/or transmitted o The specific types and details of the sensitive data involved (e.g., full track, PAN, PIN, expiry date, user IDs, passwords, etc.) o All components involved in the storage, processing, or transmission of sensitive data o All sensitive functions and resources associated with the sensitive data flow

Modified p. 16 → 17

Note: Specify all types data flows, including any output to hardcopy, paper, or other external media. The sensitive data describe here should be consistent with the information provided in Sections 2.6 through 2.8.

Note: Specify all types of data flows, including any output to hardcopy, paper, or other external media. The sensitive data describe here should be consistent with the information provided in Sections 2.6 through 2.8.

Modified p. 18 → 19

Core Requirements Module A

• Account Data Protection 3.2 Hardware Platforms and Components Tested Identify/describe all hardware platforms and components the assessed payment software was tested on/with during the assessment:

Core Requirements Module A

• Account Data Protection Requirements Module B

• Terminal Software Requirements 3.2 Hardware Platforms and Components Tested Identify/describe all hardware platforms and components the assessed payment software was tested on/with during the assessment:

Modified p. 18 → 19

Device Make / Manufacturer Device Model Name / Number Device Version (no wildcards) Device Description (e.g., device type, function, etc.) 3.3 Software Platforms and Components Tested Identify/describe all software platforms (including operating systems) and components the assessed payment software was tested on/with during the assessment:

Device Make / Manufacturer Device Model Name / Number Device PCI Approval Number (if applicable) Device Hardware and/or Firmware Version (no wildcards) Device Description (e.g., device type, function, etc.)

Modified p. 19 → 21

Document Name (including version, if applicable) Document Description / Purpose Document Generation Document Date (date last updated) Doc-1 Manual Automated Doc-2 Manual Automated Doc-3 Manual Automated Doc-4 Manual Automated Doc-5 Manual Automated

Reference Number Document Name (including version, if applicable) Document Description / Purpose Document Generation Method Document Date (date last updated) Doc-1 Manual Automated Doc-2 Manual Automated Doc-3 Manual Automated Doc-4 Manual Automated Doc-5 Manual Automated 3.6 Individuals Interviewed Identify and list the individuals interviewed during testing:

Modified p. 20 → 23

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 updates sampled in 11.1.b

Reference Number 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 Assessor Justification (for sample size chosen) Set-1 Software updates sampled in 11.1.b

Modified p. 21 → 24

4. Assessor Company Attestations A ~~duly-authorized~~ representative of the Assessor Company hereby confirms the following:

4. Assessor Company Attestations A duly authorized representative of the Assessor Company hereby confirms the following:

Modified p. 21 → 24

Note: This section must be printed and signed manually, or digitally signed using a ~~legally-recognized~~ electronic signature.

Note: This section must be printed and signed manually, or digitally signed using a legally recognized electronic signature.

Modified p. 22 → 25

5. Findings and Observations ~~Security Objective:~~ Minimizing the Attack Surface The attack surface of the software is minimized. Confidentiality and integrity of all software critical assets are protected, and all unnecessary features and ~~functionality~~ are removed or disabled.

5. Findings and Observations Minimizing the Attack Surface The attack surface of the software is minimized. Confidentiality and integrity of all software critical assets are protected, and all unnecessary features and functions are removed or disabled.

Modified p. 22 → 25

Control Objective and Test Requirements Reporting Instructions Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) Control Objective 1: Critical Asset Identification All software critical assets are identified 1.1 All sensitive data stored, processed, or transmitted by the software is identified. In Place N/A Not in Place 1.1.a The assessor shall examine vendor evidence to confirm that it details all sensitive data that is stored, processed, and/or transmitted by the software. At a minimum, this shall include all payment …

Modified p. 22 → 25

Identify the ~~vendor~~ evidence examined that ~~details~~ all ~~of the~~ sensitive data that is stored, ~~processed and/or~~ transmitted by the ~~software in accordance with this test requirement.~~

Identify the documentation and evidence examined that identifies and describes all sensitive data that is stored, processed, and transmitted by the software.

Removed p. 23

Describe what the assessor observed in the vendor evidence to conclude it details all locations where sensitive data is stored, including in temporary storage (such as volatile memory), semi- permanent storage (such as RAM disks), and non-volatile storage (such as magnetic and flash storage media).

Describe what the assessor discovered through testing to conclude that the results of the software tests are supported by the vendor evidence.

Modified p. 23 → 25

For each item of sensitive data identified in ~~Test Requirement~~ 1.1.a, identify the ~~vendor~~ evidence examined that describes where each item of sensitive data is stored (including storage in temporary locations, semi-permanent ~~locations~~ and ~~non-volatile~~ locations), and the security controls implemented to protect the sensitive data.

For each item of sensitive data identified in 1.1.a, identify the documentation and evidence examined that describes where each item of sensitive data is stored (including storage in temporary locations, semi-permanent locations, and non- volatile locations), and the security controls implemented to protect the sensitive data.

Modified p. 23 → 26

Identify the ~~vendor~~ evidence examined that describes where the implementation enforces storage within a specific location or form factor.

Identify the documentation and evidence examined that describes where the software implementation enforces storage of sensitive data within a specific location or form factor.

Removed p. 24

Describe what the assessor discovered through testing to conclude that the results of the testing are supported by the vendor evidence obtained in Test Requirement 1.1.a.

Identify the vendor evidence examined that identifies the transaction types and/or card data elements that are supported by the software.

Modified p. 24 → 26

Note: The assessor may require and rely on assistance from the vendor to ~~fulfill~~ this test requirement (such as through access to a dedicated test environment). Any such specific assistance must be documented by the assessor.

Note: The assessor may require and rely on assistance from the software vendor to complete this test requirement (such as through access to a dedicated test environment). Any such specific assistance must be documented by the assessor.

Modified p. 24 → 27

Describe each of the software tests performed ~~to identify all sensitive data that is stored, processed, and/or transmitted by~~ the ~~software (to validate~~ the ~~information obtained in Test Requirement in 1.1.a).~~

Describe each of the software tests performed in support of this test requirement, including the tool(s) or method(s) used and the scope of each test.

Removed p. 25

Identify the vendor evidence examined that describes all cryptographic implementations supported by the software, including (but not limited to) cryptography used for storage, transport, and authentication, and whether the cryptography is implemented by the software itself, through third-party software, or as functions of the execution environment.

Identify the vendor evidence examined that identifies all accounts or authentication credentials supported by the software, including both default and user created accounts.

Modified p. 25 → 26

Describe each of the software tests performed in support of this test ~~requirement.~~

Describe each of the software tests performed in support of this test requirement, including the tool(s) or method(s) used, and the scope of each test.

Removed p. 26

Describe the criteria the assessor used to determine whether configuration options provided by the software have the potential to impact sensitive data.

Modified p. 26 → 28

~~Identify~~ the ~~vendor evidence examined that outlines all~~ configuration options provided by the software ~~that can~~ impact sensitive data.

Describe the criteria the assessor used to determine whether configuration options provided by the software have the potential to impact the security of sensitive data.

Modified p. 26 → 28

Describe each of the software tests performed ~~to validate~~ the ~~configuration options specified in~~ the ~~vendor evidence.~~

Describe each of the software tests performed in support of this test requirement, including the tool(s) or method(s) used and the scope of each test.

Modified p. 26 → 29

If “yes,” identify the ~~vendor~~ evidence examined that describes all cryptographic methods and materials used to protect sensitive data.

If “yes,” identify the documentation and evidence examined that identifies and describes all cryptographic methods and materials used to protect sensitive data.

Removed p. 27

Identify the vendor evidence examined that describes how and where sensitive data associated with each sensitive function is stored, including in temporary storage, semi-permanent storage, and non-volatile storage.

Modified p. 27 → 29

Describe what the assessor observed in the ~~vendor~~ evidence ~~to conclude~~ that ~~it covers~~ all functions that are designed to store, ~~process~~ and transmit sensitive ~~data.~~

Describe what the assessor observed in the documentation, evidence and software test results that confirms that all software functions that are designed to store, process, and transmit sensitive data are documented.

Modified p. 27 → 30

~~Identify the vendor evidence examined that details all the~~ sensitive functions ~~and~~ sensitive resources provided or ~~used by the software.~~

Indicate whether any sensitive functions or sensitive resources are provided by third-party software or systems (yes/no).

Removed p. 28

Identify the vendor evidence examined that describes whether any sensitive functions are provided by third-party software or systems.

Indicate whether the software relies upon sensitive functions provided by third-party software or systems (yes/no).

Identify the available implementation guidance examined for third-party software or systems providing sensitive functions to the vendor software.

Describe what the assessor observed through testing to conclude the that vendor software is correctly following all available third-party implementation guidance.

Modified p. 28 → 30

Note: For example, by reviewing the security policy of a ~~PTS~~ or ~~FIPS140-2~~ approved cryptographic system.

Note: For example, by reviewing the security policy of a PTS, FIPS 140-2, or FIPS 140-3 approved cryptographic system.

Modified p. 28 → 31

Describe each of the software tests performed ~~to determine whether~~ the ~~vendor software is correctly following~~ the ~~implementation guidance for~~ each ~~instance where the software relies on sensitive functions provided by third- party software or systems.~~

Describe each of the software tests performed in support of this test requirement, including the tool(s) or method(s) used and the scope of each test.

Removed p. 29

Describe what the assessor discovered through testing to conclude that the results of the testing are supported by the vendor evidence examined in Test Requirement 1.2.a.

Removed p. 30

Identify the vendor evidence examined that confirms the vendor identifies and classifies critical assets.

Summarize the vendor’s classification criteria and how it classifies critical assets.

Describe what the assessor observed in the vendor evidence to conclude that an inventory of all critical assets with appropriate classifications is defined and maintained.

Modified p. 30 → 32

• The vendor defines classification criteria for identifying critical ~~assets;~~

• The vendor defines classification criteria for identifying critical assets.

Modified p. 30 → 32

• Vendor classification criteria identifies the confidentiality, integrity, and resiliency requirements for each critical ~~asset; and~~

• Vendor classification criteria identifies the confidentiality, integrity, and resiliency requirements for each critical asset.

Removed p. 31

(continued on next page) Describe each of the software tests performed to determine whether any of the functions identified in Test Requirement 2.1.a rely on external resources for authentication.

Indicate whether the software relies upon such external resources for authentication for APIs or other interfaces (yes/no).

Modified p. 31 → 33

In Place N/A Not in Place 2.1.a The assessor shall examine vendor evidence and test the software to identify any software APIs or other interfaces that are provided or exposed by default upon ~~install.~~ For each of these functions, the assessor shall confirm that the vendor has documented and justified its use as part of the software architecture. Testing shall include methods to reveal any exposed functionality of the software (such as scanning for listening services where applicable).

In Place N/A Not in Place 2.1.a The assessor shall examine vendor evidence and test the software to identify any software APIs or other interfaces that are provided or exposed by default upon installation, initialization, or first use. For each of these functions, the assessor shall confirm that the vendor has documented and justified its use as part of the software architecture. Testing shall include methods to reveal any exposed functionality of the software (such as scanning for listening services …

Modified p. 31 → 33

Describe each of the tests performed ~~to validate~~ the ~~software APIs and other interfaces specified in the vendor evidence, including those tests intended to reveal any exposed functionality~~ of ~~the software (such as scanning for listening services).~~

Describe each of the tests performed in support of this test requirement, including tool(s) or method(s) used and the scope of each test.

Modified p. 31 → 33

2.1.b The assessor shall test the software to determine whether any of the functions identified in Test Requirement 2.1.a rely on external resources for ~~authentication as required in Control Objective 5.~~ If such resources are relied upon, the assessor shall examine vendor evidence to identify what methods are required to ensure proper authentication remains in place and shall confirm that these methods are included in the assessment of all other requirements of this standard.

2.1.b The assessor shall test the software to determine whether any of the functions identified in Test Requirement 2.1.a rely on external resources for authentication. If such resources are relied upon, the assessor shall examine vendor evidence to identify what methods are required to ensure proper authentication remains in place and shall confirm that these methods are included in the assessment of all other requirements of this standard.

Removed p. 32

Indicate whether such external resources are relied upon for the protection of sensitive data during transmission (yes/no).

Removed p. 32

For each instance where the software relies upon external resources for the protection of sensitive data during transmission, identify the external resources used.

Identify the vendor evidence examined that details all methods required to ensure proper protection of sensitive data remains in place in accordance with Control Objective 6.

Modified p. 32 → 34

~~Identify the vendor evidence examined that details~~ the methods implemented by the software to ensure proper authentication remains in place for the APIs and other interfaces provided or exposed by the ~~software by default.~~

If “yes,” describe each of the methods implemented by the software to ensure proper authentication remains in place for the APIs and other interfaces provided or exposed by the software.

Modified p. 32 → 34

2.1.c The assessor shall test the software to determine whether any of the functions identified in Test Requirement 2.1.a rely on external resources for the protection of sensitive data during ~~transmission as required in Control Objective 6.~~ If such resources are relied upon, the assessor shall examine vendor evidence to identify what methods are required to ensure proper protection remains in place and shall confirm that these methods are included in the assessment of all other requirements of this standard.

2.1.c The assessor shall test the software to determine whether any of the functions identified in Test Requirement 2.1.a rely on external resources for the protection of sensitive data during transmission. If such resources are relied upon, the assessor shall examine vendor evidence to identify what methods are required to ensure proper protection remains in place and shall confirm that these methods are included in the assessment of all other requirements of this standard.

Modified p. 32 → 34

~~Describe each test performed to determine~~ whether any of the ~~functions~~ identified in ~~Test Requirement~~ 2.1.a rely on external resources for the protection of sensitive data during ~~transmission.~~

Indicate whether any of the APIs or other interfaces identified in 2.1.a rely on external resources for the protection of sensitive data during transmission (yes/no).

Removed p. 33

(continued on next page) Indicate whether any of the functions identified Test Requirement 2.1.a expose methods or services which have publicly disclosed vulnerabilities (yes/no).

Identify the vendor evidence examined that confirms the risks posed by the use the vulnerable functions, protocols, ports, etc are known and documented.

Identify the vendor evidence examined that details the mitigations implemented by the software vendor to minimize exploit of the vulnerabilities.

Describe each of the software tests performed to confirm that the vulnerabilities have been mitigated in accordance with vendor documentation.

Modified p. 33

Describe each of the software tests performed ~~to confirm whether any~~ of the ~~functions identified in Test Requirement 2.1.a expose methods or services that are vulnerable to attacks.~~

Describe each of the software tests performed in support of this test requirement, including tool(s) or method(s) used and the scope of each test.

Modified p. 33 → 35

Identify the public vulnerability repositories that were searched ~~to determine whether any of~~ the ~~functions identified~~ in ~~Test Requirement 2.1.a expose methods or services which have publicly disclosed vulnerabilities.~~

Identify the public vulnerability repositories that were searched (manually or electronically) in conjunction with the software testing in this test requirement.

Modified p. 33 → 35

• Clear and sufficient guidance on how to correctly implement sufficient security to meet the security and control objectives of this standard is made available to stakeholders per Control Objective ~~12.~~

• Clear and sufficient guidance on how to correctly implement sufficient security to meet the security and control objectives of this standard is made available to stakeholders per Control Objective 12.1.

Modified p. 33 → 36

If yes,” complete the reporting instructions for this test requirement.

If yes,” complete the remaining reporting instructions for this test requirement.

Removed p. 34

Note: The assessor should reference the vendor threat model as defined under Control Objective 4 for this item.

Identify the vendor evidence examined that confirms the vendor has made guidance available to stakeholders (in accordance with Control Objective 12) on how to correctly implement the mitigations required to minimize the exploit of the vulnerabilities. identify the page(s) or section(s) within the vendor guidance where the implementation of mitigations required to minimize the exploit of vulnerabilities is covered.

Describe any additional testing performed (in addition to the testing performed in Test Requirement 2.1.a) to identify all functions exposed by the software.

Describe what the assessor discovered through additional testing to conclude that the results of the testing are supported by the vendor documentation.

Note: The response to this reporting instruction should be consistent with the software components identified in Section 2.5.

Describe what the assessor observed in the vendor evidence to conclude that all functionality exposed …

Modified p. 35 → 37

Where access to third-party functions is prevented through implemented mitigations, the assessor shall test the software to confirm that they do not rely on a lack of knowledge of the functions as their security mitigation ~~methode.g.,~~ by simply not documenting an otherwise accessible API ~~interfaceand~~ to verify the mitigations in place are effective at preventing the insecure use of such third-party functions.

Where access to third-party functions is prevented through implemented mitigations, the assessor shall test the software to confirm that they do not rely on a lack of knowledge of the functions as their security mitigation method⎯e.g., by simply not documenting an otherwise accessible API interface⎯and to verify the mitigations in place are effective at preventing the insecure use of such third-party functions.

Modified p. 35 → 37

~~(continued on next page)~~ Identify the ~~vendor~~ evidence examined ~~that confirms the findings for~~ this test requirement.

Identify the documentation and evidence examined in support of this test requirement.

Modified p. 35 → 37

Indicate whether third-party modules ~~(i.e., functions, libraries, etc.)~~ are ~~used~~ by ~~the software~~ (yes/no).

Indicate whether any third-party modules or functions are exposed (through APIs or other interfaces) by default (yes/no).

Modified p. 35 → 38

If “no,” skip to ~~2.2.~~

If “no,” skip to 2.2.c.

Modified p. 35 → 38

Describe each of the software tests performed ~~to determine whether mitigation methods rely on a lack~~ of ~~knowledge~~ of ~~the modules/functions as their mitigation method.~~

Describe each of the software tests performed in support of this test requirement, including the tool(s) or method(s) used and the scope of each test.

Removed p. 37

Identify the vendor evidence examined that identifies all software security controls, features and functionalities implemented or provided by the software.

Describe each of the software tests performed in support of this test procedure.

Identify the vendor evidence examined that details any security controls, features or functionalities enabled by default.

If “yes,” summarize how the software prevents sensitive data from being processed until the initialization process is complete.

Modified p. 37 → 38

In Place N/A Not in Place 2.2.a The assessor shall examine vendor evidence and test the software to identify all software security features and to confirm that any ~~security~~ features relied upon by the software for the protection of critical assets are enabled upon installation, initialization, or first use of the software.

In Place N/A Not in Place 2.2.a The assessor shall examine vendor evidence and test the software to identify all software security controls, features and functions, and to confirm that any such controls, features and functions relied upon by the software for the protection of critical assets are enabled upon installation, initialization, or first use of the software.

Modified p. 37 → 38

2.2.b Where any security ~~features~~ are enabled only upon initialization or first use, the assessor shall test the software to confirm that no sensitive data can be processed until this initialization process has been completed.

2.2.b Where any software security controls, features, and functions are enabled only upon initialization or first use, the assessor shall test the software to confirm that no sensitive data can be processed until this initialization process has been completed.

Modified p. 37 → 38

Indicate whether security controls, features, and ~~functionalities relied upon for the protection of critical assets~~ are enabled only upon initialization or first use

• i.e., not upon installation (yes/no).

Indicate whether any of the software security controls, features, and functions identified in 2.2.a are enabled only upon initialization or first use, rather than upon installation (yes/no).

Removed p. 38

Indicate whether any security controls, features, and functionalities relied upon for the protection of critical assets require user input or interaction to be enabled (yes/no).

Identify the vendor security guidance examined, and the page(s) or section(s) within the guidance where the process to enable such features is covered.

Describe what the assessor observed in the vendor guidance to conclude the instructions provided in the guidance for stakeholders are appropriate for properly enabling the security controls, features, and functionalities.

Modified p. 38 → 39

~~Identify~~ the ~~vendor evidence examined that details the~~ security ~~features that~~ require user input or interaction to ~~be enabled.~~

Indicate whether any of the software security controls, features, or functions identified in 2.2.a require user input or interaction prior to being enabled (yes/no).

Removed p. 39

Describe each of the tests performed to determine whether following the vendor’s security guidance results in all security- relevant features, controls, and functionalities enabled prior to the software enabling processing of sensitive data.

Describe what the assessor observed in the vendor security guidance and through testing to conclude that following the vendor’s security guidance results in all security-relevant features, controls, and functionalities enabled prior to the software enabling processing of sensitive data.

Removed p. 40

Note: The assessor should refer to Control Objectives 1, 5, and 7 to identify authentication and access control mechanisms, keys, and other critical assets used for authentication.

Identify the vendor evidence examined that details all default credentials, keys, certificates, and other critical assets used for authentication by the software.

Describe each of the tests performed to validate the default credentials, keys, certificates and other critical assets specified in the vendor evidence.

Describe what the assessor observed through testing to conclude the results of the testing are supported by the vendor evidence examined in Test Requirement 2.3.a.

Indicate whether user input or interaction is required to disable or change any authentication credentials or keys for built-in accounts (yes/no).

Identify the vendor security guidance examined, and the page(s) or section(s) within the guidance where the process to disable or change such authentication credentials or keys is covered.

Modified p. 41

~~Identify the vendor evidence examined that details all instances where~~ user input or interaction ~~is required~~ to disable or change ~~any~~ authentication credentials or keys for built-in ~~accounts.~~

Indicate whether any authentication methods require user input or interaction to disable or change authentication credentials or keys for built-in accounts (yes/no).

Modified p. 41

2.3.d The assessor shall test the software to confirm that default authentication credentials or keys for built-in accounts are not used by the authentication and access mechanisms implemented by the ~~software.~~

2.3.d The assessor shall test the software to confirm that default authentication credentials or keys for built-in accounts are not used by the authentication and access control mechanisms implemented by the software after software installation, initialization, or first use.

Modified p. 41

Note: The assessor should refer to Control Objective 5 to ~~identify~~ authentication and access ~~mechanisms.~~

Note: The assessor should refer to evidence obtained in the testing of Control Objective 5 to determine the authentication and access control mechanisms implemented by the software.

Modified p. 41

Describe what the assessor observed in the testing results that ~~provide reasonable assurance~~ that built-in accounts are not used by the ~~authentication and access mechanisms implemented by the software.~~

Describe what the assessor observed in the software testing results that confirms that default authentication credentials or keys for built-in accounts are not used by the software after software installation, initialization, or first use.

Removed p. 42

Describe what the assessor observed in the testing results that provide reasonable assurance that default authentication credentials or keys for built-in accounts are not used to protect the storage and transmission of sensitive data.

Modified p. 42

Note: The assessor should refer to Control Objective 6 to ~~identify~~ security ~~control used~~ to protect sensitive data.

Note: The assessor should refer to evidence obtained in the testing of Control Objective 6 to determine the software security controls implemented to protect sensitive data.

Removed p. 43

Identify the vendor evidence examined that details all privileges and resources required by the software, and the vendor’s justifications for their use.

(continued on next page) Identify the vendor evidence examined that describes whether any limitations exist within the architecture of the software or its intended execution environment that would otherwise preclude restricting the software’s privileges or ability access to resources within the intended execution environment.

Indicate whether any such limitations were found to exist (yes/no).

For each instance where such limitations exist, summarize the limitations that prevent restricting the software’s privileges or ability to access resources within the intended execution environment.

Modified p. 43 → 42

Describe what the assessor observed in the ~~vendor~~ evidence ~~to conclude~~ that the vendor’s justifications for ~~all~~ privileges and resources required by the software are reasonable.

Describe what the assessor observed in the documentation and evidence that indicates that the vendor’s justifications for the privileges and resources required by the software are reasonable.

Modified p. 43 → 42

2.4.b Where limiting access is not ~~possiblee.g.,~~ due to the architecture of the solution or the execution environment in which the software is ~~executedthe~~ assessor shall examine vendor evidence to identify all mechanisms implemented by the software to prevent unauthorized access, exposure, or modification of critical assets, and to confirm there is clear and sufficient guidance on properly implementing the mechanisms provided in the ~~vendor security~~ guidance ~~documents~~ made available to stakeholders ~~per Control Objective 12.~~

2.4.b Where limiting access is not possible⎯e.g., due to the architecture of the solution or the execution environment in which the software is executed⎯the assessor shall examine vendor evidence to identify all mechanisms implemented by the software to prevent unauthorized access, exposure, or modification of critical assets, and to confirm there is clear and sufficient guidance on properly implementing the mechanisms provided in the software vendor’s implementation guidance made available to stakeholders Identify the documentation and evidence examined in support …

Removed p. 44

Identify the vendor security guidance examined, and the page(s) or section(s) within that guidance where the proper implementation of such mechanisms is covered.

Identify the tools used by the assessor to validate the privileges and access permissions.

Where the use of suitable tools is not possible, describe the assessor’s rationale for concluding that the testing performed is sufficient.

Modified p. 44

Describe each of the tests performed ~~to validate~~ the ~~privileges~~ and ~~access permissions detailed in~~ the ~~vendor evidence.~~

Describe each of the tests performed in support of this test requirement, including the tool(s) or method(s) used and the scope of each test.

Removed p. 45

Identify the vendor evidence examined that details whether the software execution environment provides any legacy features.

Indicate whether the intended software execution environment provides such legacy features (yes/no).

If “no,” skip to 2.5.

Describe each of the tests performed to determine whether the software uses any of the legacy features provided by the software execution environment.

Describe what the assessor observed in vendor evidence and discovered through testing to conclude that such legacy features are not used, and that only recent and secured functionality is implemented.

Removed p. 46

Identify the vendor evidence examined that details all the default accounts provided by the software and the privileges assigned to these accounts.

Identify the vendor evidence examined that details all of the vendor’s justifications for the privileges assigned to default accounts.

Removed p. 46

(continued on next page) Identify the vendor evidence examined that details the mechanisms implemented to protect exposed functionalities (i.e., APIs) from use by authorized users in an attempt to modify account privileges and elevate user access rights.

Modified p. 46 → 44

Describe what the assessor observed in the ~~vendor~~ evidence ~~to conclude~~ the justifications for the privileges assigned to the default accounts are reasonable.

Describe what the assessor observed in the documentation and evidence that indicates that the software vendor’s justifications for the privileges assigned to each of the default accounts are reasonable.

Removed p. 48

Describe what the assessor discovered through testing to conclude the results of software testing are supported by the vendor evidence.

Modified p. 48 → 46

Note: The assessor should refer to Control Objective 1 to ~~identify all critical assets, including~~ retained ~~sensitive data.~~

Note: The assessor should refer to evidence obtained in the testing of Control Objective 1.1 to determine the sensitive data retained by the software.

Modified p. 48 → 46

Describe what the assessor observed in the ~~vendor~~ evidence ~~to conclude~~ that the vendor’s justifications for retaining each item of sensitive data are reasonable.

Describe what the assessor observed in the documentation and evidence that indicates that the vendor’s justifications for retaining each item of persistent sensitive data are reasonable.

Modified p. 48 → 46

3.1.b The assessor shall test the software to confirm that all available functions or services designed for the retention sensitive data are supported by the vendor evidence.

3.1.b The assessor shall test the software to confirm that all available functions or services designed for the retention of sensitive data are supported by the vendor evidence.

Modified p. 48 → 46

Note: The assessor should refer to Control Objective 1 to ~~identify all~~ sensitive functions and ~~services.~~

Note: The assessor should refer to evidence obtained in the testing of Control Objective 1.2 to determine the sensitive functions and services provided or used by the software.

Removed p. 49

Describe the mechanisms implemented by the software to ensure that sensitive data storage or retention for the purposes of debugging, error finding, or testing is explicitly enabled and authorized by the user.

Describe each of the software tests performed to determine whether sensitive data stored or retained for the purposes of debugging, error finding, or testing is protected in accordance with Control Objective 6.

Describe what the assessor discovered through testing to confirm that sensitive data stored or retained for these purposes is only for a reasonable and necessary duration in accordance with vendor’s criteria for sensitive data retention.

Describe the mechanisms implemented by the software to ensure that sensitive data stored or retained for these purposes is not retained upon closure of the software.

Modified p. 49 → 46

~~Describe~~ the ~~software tests performed~~ in support of this test requirement.

Identify the documentation and evidence examined in support of this test requirement.

Modified p. 49 → 47

Indicate whether the software ~~allows for~~ sensitive data ~~to be stored or retained solely~~ for ~~the purposes of~~ debugging, error finding, or testing (yes/no).

Indicate whether the software facilitates the storage and/or retention of persistent sensitive data for debugging, error finding, or testing purposes (yes/no).

Removed p. 50

Indicate whether the retention of any sensitive data requires such user input or interaction to configure the retention period (yes/no).

Describe what the assessor observed in the vendor security guidance to conclude it provides clear and sufficient instruction for stakeholders on the proper configuration of retention periods and secure deletion procedures.

Identify the page(s) or section(s) in the vendor security guidance where configuration of retention periods and secure deletion procedures is covered.

Modified p. 50 → 48

~~Identify~~ the ~~vendor evidence examined that details whether~~ user input or interaction ~~is required~~ to configure the retention period of sensitive ~~data.~~

Indicate whether the software requires user input or interaction to configure the retention period for any persistent sensitive data stored or retained by the software (yes/no).

Removed p. 51

Identify the vendor evidence examined that details all sensitive data that is retained by the software for transient use.

Identify the vendor evidence examined that includes all justifications for retaining such data.

Modified p. 51 → 49

Describe what the assessor observed in the ~~vendor~~ evidence ~~to conclude~~ the vendor’s justifications for retaining sensitive data for transient ~~use, including sensitive data stored in memory during operation of the software,~~ are reasonable.

Describe what the assessor observed in the documentation and evidence examined that indicates that the software vendor’s justifications for retaining each item of sensitive data for transient use are reasonable.

Modified p. 51 → 49

Describe what the assessor observed in the ~~testing~~ results that ~~provides reasonable assurance that~~ the software does not use immutable ~~objects.~~

Describe what the assessor observed in the software test results that confirms the software does not use immutable objects to store transient sensitive data.

Removed p. 52

Note: This test requirement is a duplicate of 3.1.c. Reporting instructions are intentionally left blank. No further instruction needed.

3.2.d Where users can configure retention of transient sensitive data, the assessor shall examine vendor evidence to confirm that there is clear and sufficient guidance on this process, including triggering secure deletion procedure per Control Objective 3.4, is provided in the vendor security guidance documents made available to stakeholders per Control Objective 12.

Describe what the assessor observed in the vendor security guidance to conclude it provides clear and sufficient instruction for stakeholders on properly configuring the retention period for transient sensitive data and triggering the secure deletion of such data when no longer needed.

Modified p. 52 → 50

Indicate whether the retention of transient sensitive data ~~can be configured by users~~ (yes/no).

Indicate whether the software facilitates the storage or retention of transient sensitive data for debugging, error finding, or testing (yes/no).

Modified p. 52 → 51

~~(continued on next page) Identify~~ the ~~vendor evidence examined that details whether~~ users ~~can~~ configure the retention of transient sensitive ~~data.~~

Indicate whether the software enables users to configure the retention periods for transient sensitive data (yes/no).

Removed p. 54

Identify the vendor evidence examined that details the protection methods implemented for all sensitive data during storage and transmission.

Describe how the results of testing provide reasonable assurance that no additional storage of sensitive data is included beyond those methods identified in 3.3.a.

(continued on next page) Identify the vendor evidence examined that details whether sensitive data is stored outside of temporary variables within the software code.

Indicate whether such instances of sensitive data storage were found (yes/no).

Modified p. 54 → 52

Describe each of the software tests performed ~~to confirm that there is no additional storage~~ of ~~sensitive data other than that which was covered in 3.3.a.~~

Describe each of the software tests performed in support of this test requirement, including the tool(s) or method(s) used and the scope of each test.

Removed p. 55

Identify the vendor evidence examined that details all sensitive data protection methods that use cryptography.

If “yes,” describe what the assessor observed in the vendor evidence and discovered through testing to conclude that cryptographic methods used for protecting the sensitive data comply with Control Objective 7.

(continued on next page) Identify all vendor evidence examined that details whether any sensitive data is protected using methods other than strong cryptography.

Modified p. 55 → 53

3.3.d Where protection methods use cryptography, the assessor shall examine vendor evidence and test the software to confirm that the ~~method~~ complies with Control Objective 7 of this standard.

3.3.d Where protection methods use cryptography, the assessor shall examine vendor evidence and test the software to confirm that the cryptographic implementation complies with Control Objective 7 of this standard.

Modified p. 55 → 54

~~Indicate whether cryptography is~~ used to protect sensitive data stored or retained by the ~~software (yes/no).~~

Identify the cryptographic methods used to protect sensitive data stored or retained by the software.

Modified p. 55 → 54

Indicate whether ~~such~~ methods are used to protect sensitive data during storage or retention (yes/no).

Indicate whether protection methods other than strong cryptography are used to protect any sensitive data during storage or retention (yes/no).

Removed p. 56

Describe what the assessor discovered through testing to conclude the results of software testing are supported by the vendor evidence.

Removed p. 56

(continued on next page) Identify the vendor evidence examined that details whether any protection mechanisms implemented to safeguard sensitive data require user configuration to be enabled.

Describe what the assessor observed in the vendor security guidance to conclude it provides clear and sufficient instruction for stakeholders on the proper configuration of such protection mechanisms.

Modified p. 56 → 55

Describe each of the software tests performed ~~to confirm that~~ the ~~protections are present in all environments where~~ the ~~software is designed to be executed and are correctly implemented.~~

Describe each of the software tests performed in support of this test requirement, including the tool(s) or method(s) used and the scope of each test.

Modified p. 56 → 55

3.3.f Where users are required to configure protection methods, the assessor shall examine vendor evidence to confirm that there is clear and sufficient guidance on this process provided in the ~~vendor security~~ guidance ~~documents~~ made available to stakeholders per Control Objective ~~12.~~

3.3.f Where users are required to configure protection methods, the assessor shall examine vendor evidence to confirm that there is clear and sufficient guidance on this process provided in the software vendor’s implementation guidance made available to stakeholders per Control Objective 12.1.

Modified p. 56 → 55

Indicate whether the software requires user interaction to configure the protection methods identified in 3.3.a, 3.3.d and 3.3.e (yes/no).

Indicate whether the software requires user input or interaction to configure the protection methods identified in 3.3.a, 3.3.d and 3.3.e (yes/no).

Removed p. 58

Summarize the methods implemented by the software to securely delete non- transient sensitive data when no longer needed.

Indicate whether any such issues exist (yes/no).

Describe what the assessor observed in the vendor evidence and testing results to conclude that each of the secure deletion methods implemented by the software successfully render the applicable sensitive data unrecoverable.

Modified p. 58 → 57

Identify the ~~vendor~~ evidence examined that ~~details~~ all methods implemented by the software to securely delete ~~non- transient~~ sensitive data when no longer required.

Identify the documentation and evidence examined that identifies and describes all methods implemented by the software to securely delete non-transient sensitive data when no longer required.

Modified p. 58 → 57

3.4.b The assessor shall examine vendor evidence and test the software to identify any platform or implementation level issues that complicate the secure deletion of ~~such transient~~ sensitive data and to confirm that any non-transient sensitive data is securely deleted using a method that ensures that the data is unrecoverable after deletion. Methods may include (but are not necessarily limited to) overwriting the data, deletion of cryptographic keys (of sufficient strength) which have been used to encrypt the data, or …

3.4.b The assessor shall examine vendor evidence and test the software to identify any platform or implementation level issues that complicate the secure deletion of non-transient sensitive data and to confirm that any non-transient sensitive data is securely deleted using a method that ensures that the data is unrecoverable after deletion. Methods may include (but are not necessarily limited to) overwriting the data, deletion of cryptographic keys (of sufficient strength) which have been used to encrypt the data, or platform …

Modified p. 58 → 57

~~Identify the vendor evidence examined that details~~ whether any platform or ~~implementation-level~~ issues complicate secure deletion of transient sensitive ~~data.~~

Indicate whether there are any platform or implementation level issues that may complicate the secure deletion of non- transient sensitive data (yes/no).

Modified p. 58 → 57

Describe how ~~such~~ methods accommodate for platform-specific issues, such as flash ~~wear-leveling~~ algorithms or SSD over-provisioning.

Describe how the methods to render transient sensitive data unrecoverable accommodate for platform-specific issues, such as flash wear-levelling algorithms or SSD over-provisioning.

Removed p. 59

Describe how each of the software tests performed accommodates for the data structures and methods used to store non-transient sensitive data.

Describe what the assessor observed in vendor evidence and the test results that conclude that the secure deletion methods identified in 3.4.a are implemented correctly and are applied to all non-transient sensitive data.

Modified p. 59 → 58

Note: Where forensic testing of ~~the~~ some or all aspects of the platform is not possible, the assessor should examine additional evidence to confirm secure deletion of sensitive data. Such evidence may include (but is not necessarily limited to) memory and storage dumps from development systems, evidence from memory traces from emulated systems, or evidence from physical extraction of data performed on-site by the software vendor.

Note: Where forensic testing of some or all aspects of the platform is not possible, the assessor should examine additional evidence to confirm secure deletion of sensitive data. Such evidence may include (but is not necessarily limited to) memory and storage dumps from development systems, evidence from memory traces from emulated systems, or evidence from physical extraction of data performed on-site by the software vendor.

Modified p. 59 → 58

Describe each of the software tests ~~performed,~~ including the ~~details~~ of ~~the forensic tools used, to determine whether sensitive data residue is persistent in the execution environment after execution of the secure deletion methods described in 3.4.a.~~

Describe each of the software tests performed in support of this test requirement, including the tool(s) or method(s) used and the scope of each test.

Removed p. 60

Identify the vendor evidence examined that details all methods implemented by the software to securely delete the transient sensitive data once the purpose for which it is retained is satisfied.

Describe what the assessor observed in the vendor evidence to conclude that the secure deletion methods implemented by the software are sufficient to render transient sensitive data unrecoverable after deletion.

Indicate whether such issues were found to exist (yes/no).

Summarize the methods implemented by the software to compensate for such platform or implementation issues.

Describe what the assessor observed in the vendor evidence and discovered through testing to conclude the methods implemented are sufficient to minimize the risk posed by such platform or implementation issues.

Modified p. 60 → 59

In Place N/A Not in Place 3.5.a The assessor shall examine vendor evidence to identify all secure deletion methods for all transient sensitive data ~~outlined in Control Objective 3.2,~~ and to confirm that these methods ensure that the data is unrecoverable after deletion.

In Place N/A Not in Place 3.5.a The assessor shall examine vendor evidence to identify all secure deletion methods for all transient sensitive data and to confirm that these methods ensure that the data is unrecoverable after deletion.

Modified p. 60 → 59

3.5.b The assessor shall examine vendor evidence and test the software to identify any platform or implementation level issues that complicate the erasure of such transient sensitive ~~data⎯such~~ as abstraction layers between the code and the hardware execution ~~environment⎯and to confirm what methods have been implemented to minimize the risk posed by these complications.~~

3.5.b The assessor shall examine vendor evidence and test the software to identify any platform or implementation level issues that complicate the erasure of such transient sensitive data

•such as abstraction layers between the code and the hardware execution environment

Modified p. 60 → 59

~~Identify the vendor evidence examined that details~~ whether any platform or ~~implementation-level~~ issues ~~exist~~ that complicate the erasure of transient sensitive ~~data.~~

Indicate whether there are any platform or implementation level issues that may complicate the erasure of transient sensitive data (yes/no).

Removed p. 61

Describe each of the software tests performed, including the details of the forensic tools used, to determine whether transient sensitive data residue is persistent in the execution environment after execution of the secure deletion methods described in 3.5.a.

Describe what the assessor observed in vendor evidence and the test results that confirm the secure deletion methods identified in 3.5.a are implemented correctly and are applied to all transient sensitive data.

Modified p. 61 → 60

Note: Where forensic testing of ~~the~~ some or all aspects of the platform is not possible, the assessor should examine additional evidence to confirm secure deletion of sensitive data. Such evidence may include (but is not necessarily limited to) memory and storage dumps from development systems, evidence from memory traces from emulated systems, or evidence from physical extraction of data performed on-site by the software vendor.

Note: Where forensic testing of some or all aspects of the platform is not possible, the assessor should examine additional evidence to confirm secure deletion of sensitive data. Such evidence may include (but is not necessarily limited to) memory and storage dumps from development systems, evidence from memory traces from emulated systems, or evidence from physical extraction of data performed on-site by the software vendor.

Modified p. 61 → 60

Describe ~~how~~ each of the software tests performed ~~accommodate for~~ the ~~data structures~~ and ~~methods used to store transient sensitive data.~~

Describe each of the software tests performed in support of this test requirement, including the tool(s) or method(s) used and the scope of each test.

Modified p. 62 → 61

• Execution environments that may be vulnerable to remote side- channel attacks to expose sensitive ~~data⎯such~~ as attacks that exploit cache timing or branch prediction within the platform processor.

• Execution environments that may be vulnerable to remote side- channel attacks to expose sensitive data

•such as attacks that exploit cache timing or branch prediction within the platform processor.

Modified p. 62 → 61

Describe what the assessor observed in the ~~vendor~~ evidence ~~to conclude~~ that the software vendor’s analysis ~~accounted~~ for ~~each of~~ the attack vectors described in this test requirement.

Describe what the assessor observed in the documentation and evidence that confirms the software vendor’s analysis accounts for the attack vectors described in this test requirement.

Removed p. 63

Identify the vendor evidence examined that details all of the mitigations implemented by the software to protect sensitive data from disclosure through unintended channels.

Describe what the assessor observed in the vendor evidence and testing results to conclude that protection mechanisms are properly implemented to protect against the unintended disclosure of sensitive data in accordance with the vendor evidence.

Identify the page(s) or section(s) within the vendor guidance that covers the proper configuration and use of the protection mechanisms identified in 3.6.b.

Modified p. 63 → 62

3.6.c The assessor shall examine vendor evidence to confirm that clear and sufficient guidance on the proper configuration and use of such mitigations is provided in the ~~vendor security~~ guidance ~~documents~~ made available to stakeholders per Control Objective ~~12.~~

3.6.c The assessor shall examine vendor evidence to confirm that clear and sufficient guidance on the proper configuration and use of such mitigations is provided in the software vendor’s implementation guidance made available to stakeholders per Control Objective 12.1.

Removed p. 64

Describe what the assessor observed in the test results that provides reasonable assurance the software does not expose or otherwise reveal sensitive data.

Modified p. 64 → 62

Describe what the assessor observed in the testing results ~~to conclude~~ that all mitigation controls to protect against the ~~exposure~~ of sensitive data are implemented correctly.

Describe what the assessor observed in the software testing results that confirms that all mitigation controls that protect against the unintended disclosure of sensitive data are implemented correctly.

Removed p. 65

If “no,” describe how the vendor’s methodology provides equivalent methods as industry-standard methods and provides equivalent coverage of the attack scenarios applicable to the assessed software.

Modified p. 65 → 63

Identify the ~~vendor~~ evidence examined that ~~details~~ all ~~of the~~ attack scenarios ~~relevant to the software,~~ and the protection ~~mechanism~~ implemented to mitigate ~~the~~ attacks.

Identify the documentation and evidence examined that identifies and describes all software attack scenarios and the protection mechanisms implemented to mitigate those attacks.

Modified p. 65 → 63

Identify the ~~vendor~~ evidence examined that ~~details~~ the vendor’s ~~methodology~~ for determining attack ~~scenarios relevant to the vendor’s software.~~

Identify the documentation and evidence examined that identifies and describes the vendor’s method(s) for determining software attack scenarios.

Modified p. 65 → 63

Indicate whether industry-standard methods are ~~used as~~ the basis for the vendor’s ~~methodology~~ (yes/no).

Indicate whether industry-standard methods are the basis for the software vendor’s method(s) (yes/no).

Removed p. 66

• A formal owner of the software application is assigned. This may be a role for a specific individual or a specific name, but evidence must clearly show an individual who is accountable for the security of the software.

Describe what the assessor observed in the vendor evidence to conclude that cryptography and cryptographic elements, such as cipher modes, were considered in the vendor’s attack analysis.

Modified p. 66 → 64

• All critical assets managed by and sensitive resources used by the system are documented.

• All critical assets managed by and all sensitive resources used by the system are documented.

Modified p. 66 → 64

• All entry and egress methods for sensitive data by the ~~software application,~~ as well as the authentication and trust model applied to each of these entry/egress points, are defined.

• All entry and egress methods for sensitive data by the software, as well as the authentication and trust model applied to each of these entry/egress points, are defined.

Modified p. 66 → 64

(continued on next page) Identify the ~~vendor~~ evidence examined ~~that confirms the findings for~~ this test requirement.

(continued on next page) Identify the documentation and evidence examined in support of this test requirement.

Modified p. 66 → 64

Summarize the vendor’s ~~methodology~~ for defining and measuring the ~~likelihood~~ and impact of exploits ~~for~~ the assessed software.

Summarize the software vendor’s method(s) for defining and measuring the probability and impact of potential exploits against the assessed software.

Modified p. 66 → 64

Describe what the assessor observed in the ~~vendor~~ evidence ~~to conclude~~ that all entry and egress points ~~for sensitive data as well as~~ the authentication and trust model(s) applied to these ~~entry and egress~~ points ~~were~~ covered in the vendor’s attack analysis.

Describe what the assessor observed in the documentation and evidence that indicates that all sensitive data entry and egress points and the authentication and trust model(s) applied to these points are covered in the vendor’s attack analysis.

Modified p. 66 → 64

Describe what the assessor observed in the ~~vendor~~ evidence ~~to conclude~~ that all data flows, network segments, and authentication/privilege boundaries ~~of the software were~~ covered in the vendor’s attack analysis.

Describe what the assessor observed in the documentation and evidence that indicates that all software data flows, network segments, and authentication/privilege boundaries are covered in the software vendor’s attack analysis.

Modified p. 66 → 64

Describe what the assessor observed in the ~~vendor~~ evidence ~~to conclude~~ that all static IPs, domains, URLs, or ports required by the software for operation were covered in the vendor’s attack analysis.

Describe what the assessor observed in the documentation and evidence that indicates that all static IPs, domains, URLs, or ports required by the software for operation were covered in the vendor’s attack analysis.

Modified p. 67 → 65

• Consideration for the installed environment of the ~~software application,~~ including any considerations for the size of the install base are documented. All attack surfaces that must be ~~mitigated⎯such~~ as implementing insecure user prompts or separating open protocol stacks; storage of sensitive data post authorization or storage of sensitive data using insecure methods, ~~etc.⎯are documented.~~

• Consideration for the installed environment of the software, including any considerations for the size of the install base are documented. All attack surfaces that must be mitigated

•such as implementing insecure user prompts or separating open protocol stacks; storage of sensitive data post authorization or storage of sensitive data using insecure methods, etc.

Modified p. 67 → 65

Describe what the assessor observed in the ~~vendor~~ evidence ~~to conclude~~ that the software execution environment was considered in the vendor’s attack analysis.

Describe what the assessor observed in the documentation and evidence that indicates that the software execution environment was considered in the vendor’s attack analysis.

Modified p. 67 → 65

4.1.d The assessor shall examine vendor evidence to confirm that the threat model created is reasonable to address the potential risks posed by the install and use of the software in a production ~~environment⎯i.e.,~~ not in a test ~~environment⎯given~~ the assessor’s understanding through evaluation of the payment software to this standard.

4.1.d The assessor shall examine vendor evidence to confirm that the threat model created is reasonable to address the potential risks posed by the install and use of the software in a production environment

•i.e., not in a test environment

•given the assessor’s understanding through evaluation of the payment software to this standard.

Modified p. 67 → 65

Describe what the assessor observed in the ~~vendor~~ evidence ~~to conclude~~ that the ~~potential risks uniquely applicable to a production deployment of the assessed~~ software ~~were considered in the~~ vendor’s attack ~~analysis.~~

Describe what the assessor observed in the documentation and evidence that indicates that the software vendor’s attack analysis covers the use of insecure methods.

Removed p. 68

Identify the vendor evidence examined that details all of the mitigation methods implemented to address all of the threats identified in Control Objective 4.1.

Describe each of the tests performed to determine whether the mitigation methods identified in 4.2.a are properly implemented by the software.

Identify the vendor evidence examined that details whether any of the mitigations identified in 4.2.a rely on settings within the software and whether such settings and mitigations can be disabled, removed or bypassed by user input or interactions.

Modified p. 68 → 66

If “yes,” describe what the assessor observed in the ~~vendor~~ evidence ~~to conclude~~ that vendor’s justification(s) for any lack of ~~mitigations~~ is reasonable.

If “yes,” describe what the assessor observed in the documentation and evidence that indicates that the vendor’s justification(s) for any lack of mitigation is reasonable.

Modified p. 68 → 66

Describe what the assessor observed in the ~~vendor~~ evidence and ~~discovered through testing to conclude~~ that the implemented mitigation methods are appropriate for the threats they are intended to address.

Describe what the assessor observed in the documentation, evidence and software test results that indicates that the implemented mitigation methods are appropriate for the threats they are intended to address.

Modified p. 68 → 66

4.2.c Where any mitigations rely on settings within the software, the assessor shall test the software to confirm that such settings are applied by default, before first processing any sensitive data, upon ~~install~~ of the software.

4.2.c Where any mitigations rely on settings within the software, the assessor shall test the software to confirm that such settings are applied by default, before first processing any sensitive data, upon installation, initialization, or first use of the software.

Removed p. 69

Identify the vendor evidence examined that details whether any of the mitigations identified in 4.2.a rely on settings within the software and whether such settings and mitigations can be disabled, removed or bypassed by user input or interactions.

Removed p. 69

Where user input or interaction can disable, remove, or bypass any such mitigations, the assessor shall test the software to confirm that such action requires authorization and strong authentication, and examine vendor evidence to confirm that clear and sufficient guidance on the risk of this action and that installation in this manner will invalidate any security validation that has been performed is provided in the vendor security guidance documents made available to stakeholders per Control Objective 12.

Describe each of the software tests performed to determine whether such mitigations and their associated settings are applied by default.

Modified p. 69 → 67

Indicate whether any of the mitigations identified in 4.2.a rely on software settings or values (yes/no).

Indicate whether any of the mitigations identified in 4.2.a rely on software configuration settings or values (yes/no).

Modified p. 69 → 67

Describe what the assessor observed in the ~~testing~~ results ~~to conclude~~ that all such ~~settings~~ are applied by ~~default or that the software prevents processing of any sensitive data until such settings are applied.~~

Describe what the assessor observed in the documentation, evidence, and software test results that indicate that all settings and values required to configure such mitigations are applied by default.

Removed p. 70

Describe what the assessor what the assessor observed in the testing results to conclude that such actions cannot be performed without strong user authentication and authorization.

Identify the vendor guidance examined, and the page(s) or section(s) within the guidance where the risks and impacts of disabling, removing, or bypassing such mitigations are covered.

Indicate whether the protection mechanisms were found to rely on such features of the execution environment (yes/no).

Identify the vendor guidance examined, and the page(s) or section(s) within the guidance where instructions on the proper enabling, configuration and usage of such features are covered.

Modified p. 70 → 68

Where the execution environment provides APIs to query the status of mitigation controls, the assessor shall test the software to confirm that software checks ~~for~~ these mitigations are in place and active prior to being launched, and periodically throughout execution.

Where the execution environment provides APIs to query the status of mitigation controls, the assessor shall test the software to confirm that software checks that these mitigations are in place and active prior to being launched, and periodically throughout execution.

Modified p. 70 → 68

~~(continued on next page) Identify the vendor evidence examined that details~~ whether any ~~mitigations~~ rely on features of the execution ~~environment.~~

Indicate whether any protection mechanisms rely on features of the execution environment (yes/no).

Removed p. 71

If “no,” skip to Control Objective 5. if “yes,” complete the remaining reporting instructions for this test requirement.

Describe each of the software tests performed to confirm that the software checks that mitigations are in place and active during software initialization as well as throughout its execution.

Describe what the assessor observed in the results of the software testing to conclude that such checks are in place and active (by default).

Modified p. 71 → 68

Indicate whether the execution environment provides any ~~such~~ APIs (yes/no).

Indicate whether the intended execution environment provides any APIs to query the status of mitigation controls (yes/no).

Removed p. 72

Identify the vendor evidence examined that details all of the authentication requirements for all roles, based on critical access classification, the type of access and the level of privilege.

Identify the vendor evidence examined that details all of the authentication implemented to control access to critical assets.

Modified p. 72 → 70

Note: The assessor should refer to Control Objective 1 to ~~identify asset classification and~~ all critical assets.

Note: The assessor should refer to evidence obtained in the testing of Control Objective 1.3 to determine the classifications for all critical assets.

Modified p. 72 → 70

Describe what the assessor observed in the ~~testing~~ results ~~to conclude~~ that the authentication mechanisms implemented ~~correctly in accordance with the vendor evidence.~~

Describe what the assessor observed in the documentation, evidence, and software test results that indicate that each of the authentication mechanisms are implemented correctly.

Removed p. 73

Indicate whether the software relies on or facilitates such use of additional mechanisms for secure non-console access (yes/no).

Identify the vendor evidence examined that details all critical assets identified by the software vendor.

Modified p. 73 → 71

~~Identify the vendor evidence examined that details~~ whether the software ~~recommends, suggests,~~ relies ~~on,~~ or ~~otherwise facilitates~~ the use of additional mechanisms ~~to facilitate~~ non-console access to the software ~~or its underlying system.~~

Indicate whether the software relies on or supports the use of additional mechanisms for secure non-console access to the software (yes/no).

Modified p. 73 → 71

Identify the ~~vendor~~ evidence ~~examined, and~~ the ~~page(s) or section(s) within~~ the ~~guidance where instructions on the proper configuration such authentication methods are provided.~~

Identify the documentation and evidence that contains the software vendor’s guidance on configuring additional authentication mechanisms for secure non-console access to the software.

Modified p. 73 → 71

Describe what the assessor observed in the ~~vendor~~ evidence ~~to conclude~~ that ~~any~~ data associated with authentication credentials is treated as a critical ~~asset and protected accordingly.~~

Describe what the assessor observed in the documentation and evidence that indicates that all data associated with authentication credentials is treated as a critical asset.

Removed p. 74

Identify the vendor evidence examined that details all identification and authentication methods implemented by the software.

(continued on next page) Identify the vendor evidence examined that details whether interfaces, such as APIs, allow for automated access to critical access.

Describe what the assessor observed in the testing results to conclude that access to the software’s critical assets by different programs or systems requires unique authentication.

Modified p. 74 → 72

Describe what the vendor observed in the ~~vendor evidence~~ and ~~testing~~ results ~~to conclude~~ that all implemented authentication methods require unique identification.

Describe what the vendor observed in the documentation, evidence, and software test results that confirms that all implemented authentication methods require unique identification.

Modified p. 74 → 72

5.2.b Where interfaces, such as APIs, allow for automated access to critical assets, the assessor shall examine vendor evidence and test the software to confirm that unique identification of different programs or systems accessing the critical assets is required (for example, through use of multiple public keys) and that guidance on configuring a unique credential for each program or system is included in the ~~vendor security~~ guidance ~~documents~~ made available to stakeholders per Control Objective ~~12.~~

5.2.b Where interfaces, such as APIs, allow for automated access to critical assets, the assessor shall examine vendor evidence and test the software to confirm that unique identification of different programs or systems accessing the critical assets is required (for example, through use of multiple public keys) and that guidance on configuring a unique credential for each program or system is included in the software vendor’s implementation guidance made available to stakeholders per Control Objective 12.1.

Modified p. 74 → 72

Indicate whether the software provides ~~such~~ interfaces to enable automated access to critical assets (yes/no).

Indicate whether the software provides APIs or other interfaces to enable automated access to critical assets (yes/no).

Removed p. 75

Note: The assessor should refer to Control Objective 6 to identify controls to protect sensitive data at rest and in transit.

Indicate whether such identification is supplied (yes/no).

Identify the page(s) or section(s) within the vendor guidance where users are instructed not to share identification and authentication parameters between individuals or programs.

Modified p. 75 → 73

~~Identify the vendor evidence examined that details~~ whether ~~user or system~~ identification is supplied across a ~~non- console interface.~~

Indicate whether identification is supplied across a non-console interface (yes/no).

Modified p. 75 → 73

~~Describe~~ the ~~software tests performed to determine~~ in support of this test requirement.

Identify the documentation and evidence examined in support of this test requirement.

Modified p. 75 → 74

Describe what the assessor observed in the ~~testing results to conclude~~ that the ~~authentication mechanisms are appropriately protected.~~

Describe what the assessor observed in the documentation, evidence, and source code that indicates that the software provides no additional methods, other than those identified in 5.2.a.

Modified p. 75 → 74

Identify the ~~vendor~~ evidence examined that ~~confirms~~ the ~~vendor provides security~~ guidance on the ~~proper~~ use of identification and authentication ~~parameters in accordance with Control Objective 12.~~

Identify the documentation and evidence examined that contains the software vendor’s guidance on the use of identification and authentication parameters.

Removed p. 76

Describe what the assessor observed in the vendor evidence to conclude that no additional methods (other than those identified in 5.2.a) are provided by the software.

Modified p. 76 → 74

~~Identify~~ the ~~vendor evidence~~ examined that ~~details all~~ methods for accessing critical assets.

Describe how and the extent to which source code was examined to confirm that the software provides no other methods for accessing critical assets.

Modified p. 76 → 74

~~Describe the extent to which the~~ source code ~~was examined~~ to confirm there are no ~~other~~ methods for accessing critical ~~assets are provided by the software.~~

5.2.e The assessor shall examine vendor evidence, including source code of the software, to confirm that there are no additional methods for accessing critical assets.

Removed p. 77

Describe what the assessor observed in the vendor evidence to conclude that all known vulnerabilities and attack methods identified are mitigated in the software implementation.

Identify the vendor evidence examined that details the vendor’s evaluation of the robustness of the authentication methods implemented by the software.

Modified p. 77 → 75

Describe what the assessor observed in the ~~vendor~~ evidence ~~to conclude~~ that ~~all implemented~~ authentication ~~methods were~~ evaluated to identify ~~any~~ known ~~vulnerabilities~~ or ~~attack methods for each implemented~~ authentication method.

Describe what the assessor observed in the documentation and evidence that confirms that the implementation of each authentication method was evaluated to identify known vulnerabilities, attack methods, vectors, or patterns that might enable an attacker to compromise or, otherwise, circumvent the authentication method.

Modified p. 77 → 75

Describe the methods used to evaluate the robustness of the implemented authentication methods and how they are consistent with industry-accepted methods.

Describe the methods used by the software vendor to evaluate the robustness of the implemented authentication methods and how they are consistent with industry-accepted methods.

Modified p. 77 → 76

Note: The vendor assessment and robustness justification include consideration of the full path of the user credentials, from any input source (such as a Human Machine Interface or other program), through transition to the execution environment of the software (including any switched/network transmissions and traversal through the execution environment’s software stack before being processed by the software ~~application~~ itself).

Note: The vendor assessment and robustness justification include consideration of the full path of the user credentials, from any input source (such as a Human Machine Interface or other program), through transition to the execution environment of the software (including any switched/network transmissions and traversal through the execution environment’s software stack before being processed by the software itself).

Modified p. 77 → 76

Describe what the assessor observed in the ~~vendor~~ evidence ~~to conclude~~ that the implemented authentication methods are reasonably sufficient to protect them from being forged, spoofed, leaked, ~~guessed~~ or circumvented.

Describe what the assessor observed in the documentation and evidence that indicates that the implemented authentication methods are reasonably sufficient to protect them from being forged, spoofed, leaked, guessed, or circumvented.

Modified p. 78 → 76

Describe each of the software tests performed ~~to determine whether authentication methods are implemented correctly.~~

Describe each of the software tests performed in support of this test requirement, including the tool(s) or method(s) used and the scope of each test.

Modified p. 78 → 76

Describe what the assessor observed in the ~~testing~~ results that provides reasonable assurance that the authentication mechanisms are correctly ~~implemented~~ and do not expose vulnerabilities.

Describe what the assessor observed in the software test results that provides reasonable assurance that the authentication mechanisms are implemented correctly and do not expose vulnerabilities.

Removed p. 79

Identify the vendor evidence examined that identifies and justifies the access required for all critical assets.

Describe the software tests performed to identify the level of access provided to each critical asset.

Describe what the assessor observed in the testing results to conclude that the results of the software testing are supported by the vendor evidence.

Modified p. 79 → 77

Describe what the assessor observed in the ~~vendor~~ evidence ~~to conclude~~ that the access requirements for each critical asset are ~~reasonably justified.~~

Describe what the assessor observed in the documentation and evidence that indicates that the access requirements and justification(s) for each critical asset are reasonable for the software’s intended function.

Removed p. 80

Identify the vendor evidence examined that details all locations where sensitive data is stored by the software.

Removed p. 80

(continued on next page) Identify the vendor evidence examined that details all of the security methods implemented to protect sensitive data during storage.

Modified p. 80 → 78

Describe what the assessor observed in the ~~vendor~~ evidence ~~to conclude~~ that protection requirements for all sensitive data stored by the ~~software, including requirements for rendering sensitive data with confidentiality considerations unreadable anywhere sensitive data is stored persistently,~~ are defined.

Describe what the assessor observed in the documentation and evidence that indicates that protection requirements for all sensitive data stored by the software are defined.

Removed p. 81

Describe what the assessor discovered through software testing to conclude the results of the tests are supported by the vendor evidence.

Identify the vendor evidence examined that details whether cryptography is used for protecting sensitive data during storage.

Indicate whether cryptography is used for such purposes (yes/no).

Describe what the assessor observed in the vendor evidence and the testing results to conclude that all instances where cryptography is used for securing sensitive data, the cryptography is compliant with Control Objective 7.

Modified p. 81 → 78

Describe what the assessor observed in the ~~vendor evidence~~ and ~~in the testing~~ results ~~to conclude~~ that ~~the~~ security methods implemented to protect sensitive data during storage ~~or retention appropriately~~ address all defined protection requirements and identified attack scenarios.

Describe what the assessor observed in the documentation, evidence, and software test results that indicates that security methods implemented to protect sensitive data during persistent storage properly address all defined protection requirements and identified attack scenarios.

Removed p. 82

Indicate whether index tokens are used for such purposes (yes/no).

Describe what the assessor observed in the vendor evidence and the testing results to conclude that index tokens are generated in a way that ensures there is no correlation between the value and the sensitive data being referenced (without access to the vendor software to perform correlation as part of a formally defined and assessed feature of that software

• such as “de-tokenization”).

Modified p. 82 → 80

~~Identify~~ the ~~vendor evidence examined that details whether~~ index tokens ~~are used~~ for securing sensitive data during ~~storage.~~

Indicate whether the software uses index tokens for securing sensitive data during persistent storage (yes/no).

Removed p. 83

Describe what the assessor observed in the vendor evidence and the testing results to conclude that the security properties upon which the protection mechanisms rely exist for all platforms targeted by the software.

Describe what the assessor observed in the vendor evidence and the testing results to conclude that protection mechanisms which rely on such security properties are appropriate for protecting the sensitive data.

Modified p. 83 → 80

Identify the ~~vendor~~ evidence examined ~~that details whether protection methods rely on security properties~~ of ~~the execution environment.~~

Identify the documentation and evidence examined in support of this test requirement.

Modified p. 83 → 81

Indicate whether any protection mechanisms implemented by the software to safeguard sensitive data rely on security properties ~~of the execution environment~~ (yes/no).

Indicate whether any protection mechanisms implemented by the software to safeguard sensitive data rely on execution environment security properties (yes/no).

Removed p. 84

Identify the vendor evidence examined that details whether protection methods rely on security properties provided by third-party software.

Describe what the assessor observed in the vendor evidence and the testing results that provides reasonable assurance that there are no unmitigated vulnerabilities in the third-party software that provides the security properties the protection mechanisms rely upon.

Modified p. 84 → 82

Indicate whether ~~any~~ protection mechanisms implemented by the software to safeguard sensitive data rely on ~~the~~ security properties ~~of third-party software~~ (yes/no).

Indicate whether protection mechanisms implemented by the software to safeguard sensitive data rely on third- party software security properties (yes/no).

Removed p. 85

Identify the vendor evidence examined that details all locations where sensitive data is transmitted by the software.

Describe what the assessor discovered through software testing to conclude that the results of the testing are supported by the vendor evidence.

(continued on next page) Identify the vendor evidence examined that details all of the ingress and egress points where sensitive data with confidentiality considerations is transmitted outside of the physical execution environment.

Modified p. 85 → 83

~~Describe each of~~ the ~~software tests performed~~ in support of this test requirement.

Identify the documentation and evidence examined in support of this test requirement.

Modified p. 85 → 83

Describe what the assessor observed in the ~~vendor~~ evidence ~~examined~~ that protection requirements are defined for all locations where sensitive ~~data is transmitted by the software.~~

Describe what the assessor observed in the documentation and evidence that confirms protection requirements are defined for all locations where the software transmits sensitive data.

Modified p. 85 → 83

Note: The assessor should refer to Control Objective 1 to ~~identify all critical assets.~~

Note: The assessor should refer to evidence obtained in the testing of Control Objective 1.1 to determine the sensitive data stored, processed, or transmitted by the software.

Removed p. 86

6.2.c Where third-party or execution- environment features are relied upon for the security of the transmitted data, the assessor shall examine vendor evidence to confirm that clear and sufficiently detailed instructions allowing for the secure settings to be applied during installation and operation of the vendor application are included in the vendor security guidance made available to stakeholders per Control Objective 12.

Indicate whether third-party or execution-environment features are relied upon for the security of transmitted sensitive data (yes/no).

Identify the vendor evidence examined that confirms the vendor provides clear and sufficient guidance on the correct configuration and use of such third-party or execution environment features in accordance with Control Objective 12.

Identify the page(s) or section(s) within the vendor guidance where the instructions on the secure configuration and use of such third-party or execution environment features are provided.

Modified p. 86 → 84

~~Identify~~ the ~~vendor evidence examined that details whether~~ third-party or ~~execution~~ environment features ~~are relied upon for~~ the ~~protection~~ of sensitive data ~~transmissions.~~

Indicate whether the software relies upon any third-party or execution- environment features to ensure the security of transmitted sensitive data (yes/no).

Removed p. 87

If “no,” skip to 6.2.e.

Removed p. 87

Describe what the assessor observed in the testing results to conclude that all ingress and egress methods enforce secure versions of the (TLS) protocol with end-point authentication prior to the transmission of the sensitive data.

Modified p. 87 → 85

~~Identify the vendor evidence examined that details~~ whether transport layer encryption is used to secure the transmission of sensitive ~~data.~~

Indicate whether transport layer encryption is used (TLS) to secure the transmission of sensitive data (yes/no).

Modified p. 87 → 85

~~Indicate~~ whether transport layer encryption is used ~~(i.e., “TLS”)~~ to secure the transmission of sensitive ~~data (yes/no).~~

Describe what the assessor observed in the documentation, evidence, and software test results that confirms whether transport layer encryption is used to secure the transmission of sensitive data.

Removed p. 88

Indicate whether the methods implemented to encrypt sensitive data for transmission allow for the use of different types of cryptography or different levels of security (yes/no).

Modified p. 88 → 86

~~Identify~~ the ~~vendor evidence examined that details whether~~ methods implemented ~~for encrypting~~ sensitive data allow for the use of different types of cryptography or different levels of ~~security.~~

Indicate whether the methods implemented by the software to encrypt sensitive data for transmission allow for the use of different types of cryptography or different levels of security (yes/no).

Modified p. 88 → 86

Describe what the assessor observed in the ~~testing~~ results ~~to conclude~~ that ~~the~~ strong cryptography is enforced at all times ~~(by~~ the ~~software)~~ during transmission.

Describe what the assessor observed in the documentation, evidence, and software test results that confirms strong cryptography is enforced at all times by the software during transmission.

Removed p. 89

6.3.b Where third-party software or aspects of the execution environment or platform on which the application is run are relied upon for cryptographic services for the protection of sensitive data, the assessor shall examine vendor evidence and test the software to identify these methods and to confirm that the vendor security guidance provides clear and sufficient detail for correctly configuring these methods during the installation of the vendor software.

(continued on next page) Identify the vendor evidence examined that details whether the software relies on any third-party software or aspects of the execution environment for cryptographic services to protect sensitive data.

Indicate whether the software relies upon such cryptographic services for the protection of sensitive data (yes/no).

Describe what the vendor discovered through software testing to conclude the results of the testing are supported by the vendor evidence.

Modified p. 89 → 87

~~Describe each of~~ the ~~tests performed~~ in support of this test requirement.

Identify the documentation and evidence examined in support of this test requirement.

Modified p. 89 → 87

Describe what the assessor observed in the ~~vendor evidence~~ and test results ~~to conclude~~ that all uses of cryptography for the purpose of securing critical assets ~~is compliant to~~ Control Objective 7.

Describe what the assessor observed in the documentation, evidence, and software test results that indicate that all uses of cryptography for the purpose of securing critical assets complies with Control Objective 7.

Removed p. 90

Indicate whether asymmetric cryptography (such as RSA or ECC) is used for protecting the confidentiality of sensitive data (yes/no).

Describe what the assessor discovered through software testing to conclude the results of the testing are supported by the vendor evidence.

Describe what the assessor observed in the vendor evidence and testing results that provides reasonable assurance that private keys are not used for to protect the confidentiality of sensitive data.

Modified p. 90 → 88

~~Identify the vendor evidence examined that details~~ whether asymmetric cryptography is used for ~~protecting~~ the confidentiality of sensitive ~~data.~~

Indicate whether asymmetric cryptography (such as RSA or ECC) is used for to protect the confidentiality of sensitive data (yes/no).

Removed p. 91

If “yes,” identify the unapproved algorithms or modes of operation used and describe how they are used in conjunction with approved algorithms in a manner that ensures equivalent cryptographic key strength as the approved algorithms.

Modified p. 91 → 89

In Place N/A Not in Place 7.1.a The assessor shall examine the vendor evidence to confirm that, where ~~that~~ cryptography is relied upon (in whole or in part) for the security of the critical assets:

In Place N/A Not in Place 7.1.a The assessor shall examine the vendor evidence to confirm that, where cryptography is relied upon (in whole or in part) for the security of the critical assets:

Modified p. 91 → 89

Indicate whether the software uses any unapproved cryptographic algorithms or modes of operation (yes/no).

Indicate whether the software uses any unapproved cryptographic algorithms or modes of operation to protect critical assets (yes/no).

Removed p. 92

Note: The assessor should refer to Control Objective 4 to identify common cryptography attacks.

Describe what the assessor observed in the vendor evidence and testing results to conclude that each of the cryptographic algorithms and modes of operation in use are implemented correctly (i.e., are fit-for-purpose).

Indicate whether any of the implemented cryptographic algorithms (and their supporting modes of operation) require a unique value per encryption operation or session (yes/no).

Modified p. 92 → 90

Describe what the assessor observed in the ~~vendor evidence~~ and ~~testing~~ results ~~to conclude~~ that only documented cryptographic algorithms and modes of operation are used in the software.

Describe what the assessor observed in the documentation, evidence, and software test results that confirms that only documented cryptographic algorithms and modes of operation are used in the software.

Modified p. 92 → 90

~~Identify~~ the ~~protection~~ mechanisms implemented to protect against common cryptographic attacks.

Describe the mechanisms implemented to protect the cryptographic algorithms and modes of operation used by the software against common cryptographic attacks.

Modified p. 92 → 91

~~(continued on next page) Identify the vendor evidence examined that details~~ whether any cryptographic algorithms or modes of operation ~~used by the software~~ require a unique value per encryption operation or ~~session.~~

Indicate whether any of the implemented cryptographic algorithms and supporting modes of operation require a unique value per encryption operation or session (yes/no).

Removed p. 93

Describe what the assessor observed in the vendor evidence and testing results to conclude that the cryptographic algorithms and their supporting modes of operation are implemented in such a way that mitigates all known vulnerabilities.

Identify the vendor evidence examined that details whether padding methods are used prior to or during encryption operations.

Indicate whether padding is used prior to or during encryption operations (yes/no).

Modified p. 93 → 92

Describe what the assessor observed in the ~~vendor evidence~~ and ~~testing~~ results ~~to conclude~~ that whenever an encryption operation uses padding, it always uses an ~~industry-accepted~~ standard padding method.

Describe what the assessor observed in the documentation, evidence, and software test results that confirms that whenever an encryption operation uses padding, it always uses an industry- accepted standard padding method.

Removed p. 94

Identify the vendor evidence that details whether has functions are used within the software.

Describe what the assessor observed in the testing results to conclude that only approved, collision-resistant hash algorithms and methods are used.

Describe what the assessor observed in the testing results to conclude that all hash algorithms used leverage a salt value of approved strength that is generated using a secure random number generator.

Modified p. 94 → 92

Note: The assessor should refer to Control Objective 7.3 ~~to identify~~ secure random number generators.

Note: The assessor should refer to Control Objective 7.3 for more information on secure random number generators.

Modified p. 94 → 92

Indicate whether hash functions ~~are used~~ (yes/no).

Indicate whether the software uses any hash functions for the protection of sensitive data (yes/no).

Removed p. 95

Describe what the assessor observed in the testing results to conclude that all cryptographic keys used for providing security to critical assets or other security services to the software have a unique purpose in accordance with the vendor evidence.

Describe what the assessor observed in the testing results to conclude that All cryptographic keys have an equivalent bit strength of at least 128 bits in accordance with industry standards and the vendor evidence.

Modified p. 95 → 94

(continued on next page) Identify the ~~vendor~~ evidence examined ~~that confirms the findings for~~ this test requirement.

(continued on next page) Identify the documentation and evidence examined in support of this test requirement.

Modified p. 95 → 94

• All cryptographic keys that are used for providing security to critical ~~assets⎯including~~ both confidentiality and ~~authenticity⎯as~~ well as for providing other security services to the software (such as authentication of end-point or ~~application~~ updates) have a unique purpose. For example, no key may be used for both encryption and authentication operations.

• All cryptographic keys that are used for providing security to critical assets

•including both confidentiality and authenticity

•as well as for providing other security services to the software (such as authentication of end-point or software updates) have a unique purpose. For example, no key may be used for both encryption and authentication operations.

Modified p. 95 → 94

• All keys have defined generation methods, and no secret or private cryptographic keys relied upon for security of critical assets are shared between software instances, except when a common secret or private key is used for securing the storage of other cryptographic keys that are generated during the ~~installation~~ of the ~~application~~ (e.g., white-box cryptography).

• All keys have defined generation methods, and no secret or private cryptographic keys relied upon for security of critical assets are shared between software instances, except when a common secret or private key is used for securing the storage of other cryptographic keys that are generated during the installation, initialization, or first use of the software (e.g., white-box cryptography).

Modified p. 95 → 94

Describe each of the software tests performed in support of this test ~~requirement.~~

Describe each of the software tests performed in support of this test requirement, including the tool(s)j or method(s) used and the scope of each test.

Modified p. 95 → 94

Describe what the assessor observed in the ~~testing~~ results ~~to conclude~~ that all keys have defined generation methods, and no secret or private cryptographic keys relied upon for the security of critical assets are shared between software instances, except when a common secret or private key is used ~~for securing~~ the storage of other cryptographic keys that are generated during the ~~installation~~ of the ~~application in accordance with the vendor evidence.~~

Describe what the assessor observed in the documentation, evidence, and software test results that confirms that all keys have defined generation methods, and no secret or private cryptographic keys are relied upon for the security of critical assets that are shared between software instances, except when a common secret or private key is used to secure the storage of other cryptographic keys that are generated during the installation, initialization, or first use of the software.

Modified p. 96 → 95

Describe what the assessor observed in the ~~testing~~ results ~~to conclude~~ that all keys have a defined crypto-period aligned with industry standards, and methods are implemented to retire and/or update each key at the end of the defined ~~crypto-period in accordance with the vendor evidence.~~

Describe what the assessor observed in the documentation, evidence, and software test results that confirms that all cryptographic keys have an equivalent bit strength of at least 128 bits, in accordance with industry standards Describe what the assessor observed in the documentation, evidence, and software test results that confirms that all keys have a defined crypto-period aligned with industry standards, and that methods are implemented to retire and/or update each key at the end of the defined crypto-period.

Modified p. 96 → 95

Describe what the assessor observed in the ~~testing~~ results ~~to conclude~~ that all keys have a defined generation or injection process, and ~~this~~ process ensures sufficient entropy for the ~~key in accordance with the vendor evidence.~~

Describe what the assessor observed in the documentation, evidence, and software test results that confirms that all keys have a defined generation or injection process, and that the process ensures sufficient entropy for the key.

Modified p. 96 → 95

Describe what the assessor observed in the ~~testing~~ results ~~to conclude~~ that all key-generation functions ~~must~~ implement ~~one-way~~ functions or other irreversible ~~key-generation~~ processes, and no reversible key calculation modes are used to directly create new keys from an existing ~~key in accordance with the vendor evidence.~~

Describe what the assessor observed in the documentation, evidence, and software test results that indicates that all key-generation functions implement one- way functions or other irreversible key- generation processes, and that no reversible key calculation modes are used to directly create new keys from an existing key.

Modified p. 96

Describe what the assessor observed in the ~~testing~~ results ~~to conclude~~ that ~~the integrity and confidentiality of all secret and private cryptographic keys managed by~~ the software ~~are protected when stored in accordance with the vendor evidence.~~

Describe what the assessor observed in the documentation, evidence, and software test results that confirms whether the software uses cryptography to protect cryptographic keys.

Removed p. 97

Identify the vendor evidence examined that details whether cryptography is used for the protection of any cryptographic keys and the effective key strengths provided by such keys.

Modified p. 97 → 96

Indicate whether cryptography ~~is used~~ to protect any cryptographic keys (yes/no).

Indicate whether the software uses cryptography to protect any cryptographic keys (yes/no).

Modified p. 97 → 96

~~Describe~~ what the assessor observed in the ~~vendor evidence~~ and ~~testing~~ results that ~~demonstrates~~ that all cryptographic keys used to protect other cryptographic keys provide an effective key strength equal or greater to the keys they protect.

If “yes,” describe what the assessor observed in the documentation, evidence, and software test results that confirms that all cryptographic keys used to protect other cryptographic keys provide an effective key strength equal to or greater than the keys they protect.

Modified p. 98 → 97

• Key length Identify the ~~vendor~~ evidence examined ~~that details whether public keys are used by the software.~~

• Key length Identify the documentation and evidence examined in support of this test requirement.

Modified p. 98 → 97

Indicate whether public keys ~~are used by the system~~ (yes/no).

Indicate whether the software uses public keys (yes/no).

Modified p. 98 → 97

Identify the ~~vendor~~ evidence ~~examined~~ that ~~confirms~~ the ~~vendor maintains an~~ inventory of all cryptographic keys ~~in use.~~

Identify the documentation and evidence that contains the software vendor’s inventory of all cryptographic keys used by the software.

Modified p. 98 → 97

Describe what the assessor observed in the ~~vendor evidence~~ and ~~testing~~ results ~~to conclude~~ that the authenticity of all public keys used in the software is maintained.

Describe what the assessor observed in the documentation, evidence, and software test results that confirms that the authenticity of all public keys used in the software is maintained.

Removed p. 99

If “no,” skip to 7.2.e If “yes,” complete the remaining reporting instructions for this test requirement.

Identify the vendor evidence examined that details the methods and procedures implemented by the software to revoke and/or replace such keys (or key pairs).

Describe each of the software tests performed to confirm that the methods and procedures implemented to revoke and/or replace such keys are supported by the vendor evidence.

Modified p. 99 → 98

~~Identify the vendor evidence examined that details~~ whether public or white-box keys are used that are not unique ~~per~~ each software ~~instantiation.~~

Indicate whether any public or white-box keys are used by the software that are not unique to each software instance (yes/no).

Modified p. 99 → 98

~~Indicate whether~~ public or white-box keys ~~are~~ used by the software that are not unique to each software ~~instantiation (yes/no).~~

If “yes,” for each public or white-box keys used by the software that are not unique to each software instance, describe how the software (or the software vendor) revokes and/or replaces such keys (or key pairs).

Removed p. 100

Identify the vendor evidence examined that confirms the vendor provides clear and sufficient guidance (in accordance with Control Objective 12) on how to install such key material.

Identify the page(s) or section(s) within the vendor guidance where the proper installation of such key material is covered.

Modified p. 100 → 98

~~Identify~~ the ~~vendor evidence examined~~ that ~~details whether~~ the software relies upon external files or other data elements for cryptographic ~~key material.~~

Describe what the assessor observed in the documentation, evidence, and software test results that indicates that the software relies upon external files or other data elements for cryptographic materials.

Modified p. 100 → 99

If “no,” skip to ~~7.2.f~~ If “yes,” complete the ~~remining~~ reporting instructions for this test requirement.

If “no,” skip to 7.2.g If “yes,” complete the remaining reporting instructions for this test requirement.

Removed p. 101

Identify the vendor evidence that details whether public keys are used by the software, and whether such keys are manually loaded or used as root keys.

If “no,” skip to 7.2.g If “yes,” complete the remining reporting instructions for this test requirement.

Indicate whether vendor evidence examination or the results of software testing indicate that complete dual control of manual key loading or usage is infeasible (yes/no).

If “no,” skip to 7.2.g.

Describe the methods implemented to protect the public keys and why they are appropriate for that purpose.

Modified p. 101 → 99

Indicate whether any public keys ~~used by the software are manually loaded~~ or ~~used~~ as root keys (yes/no).

Indicate whether the software uses any manually loaded public keys or uses public keys as root keys (yes/no).

Modified p. 101 → 99

Describe each of the software tests performed ~~to confirm that~~ the ~~public keys are installed~~ and ~~stored in a way that provides dual control.~~

Describe each of the software tests performed in support of this test requirement, including the tool(s)/method(s) used and the scope of each test.

Modified p. 101 → 99

Describe ~~the~~ circumstances that make the implementation of complete dual control infeasible.

Describe any circumstances that make the implementation of complete dual control over manually loaded or root keys infeasible. Also describe the methods implemented to protect the public keys in the absence of dual control.

Removed p. 102

Identify the vendor evidence examined that details how all secret and private keys are managed.

Indicate whether vendor evidence examination or the results of software testing indication absolute split knowledge of the secret/private keys is infeasible (yes/no).

If “no,” skip to 7.2.h.

Describe the circumstances that make the implementation of split knowledge infeasible.

Describe the methods implemented to protect secret and/or private keys and why the protection methods are reasonable for their intended purpose.

Modified p. 102 → 100

Describe each of the software tests performed ~~to confirm~~ the ~~methods implemented by~~ the ~~software to manage secret and private keys are implemented in a way that ensures split knowledge over the key.~~

Describe each of the software tests performed in support of this test requirement, including the tool(s)/method(s) used and the scope of each test.

Removed p. 103

Identify the vendor evidence examined that details the methods implemented by the software to “roll” any keys at the end of their crypto-period.

Modified p. 103 → 101

Describe each of the software tests performed ~~to confirm~~ the ~~methods implemented by~~ the ~~software to “roll” any keys at the end~~ of ~~their crypto-period are implemented in a manner consistent with the vendor evidence.~~

Describe each of the software tests performed in support of this test requirement, including the tool(s)/method(s) used and the scope of each test.

Removed p. 104

Identify the vendor evidence examined that confirms all random number generation methods implemented in the software are implemented in a manner consistent with this test requirement.

Modified p. 104 → 102

Describe what the assessor observed in the ~~vendor~~ evidence that ~~demonstrates~~ all random number generation methods implemented use at least 128 bits of entropy prior to the output of any random numbers from the random number generator.

Describe what the assessor observed in the documentation and evidence that confirms all random number generation methods implemented use at least 128 bits of entropy prior to the output of any random numbers from the random number generator.

Modified p. 104 → 102

Describe what the assessor observed in the ~~vendor~~ evidence that ~~provides reasonable assurance~~ that sufficient entropy ~~(i.e., at~~ least 128 bits) is always provided or produced upon start-up or entry of other ~~predicable~~ states of the system.

Describe what the assessor observed in the documentation and evidence that confirms that sufficient entropy (at least 128 bits) is always provided or produced upon start-up or entry of other predictable states of the system.

Removed p. 105

Identify the vendor evidence examined that details whether any random number generators or “seeds” used by the software rely on a previous assessment to meet this control objective.

Identify the vendor evidence examined that details the scope of the previous assessment (and approval).

Describe what the assessor observed in the vendor evidence to conclude that correct areas of the software were included in the previous assessment of the random number generator, and that all vendor claims do not exceed the scope of evaluation or approval of that software.

Removed p. 106

Where problems are known, but have been mitigated by the application vendor, the assessor shall examine vendor evidence and test the software to confirm that the vulnerabilities have been sufficiently mitigated.

Indicate whether third-party software, platforms, or libraries are used for all or part of the random number generation process (yes/no).

Identify the publicly-available literature examined to determine whether known problems (i.e., vulnerabilities) exist in the third-party software, platforms or libraries used for random number generation.

Indicate whether any known problems were identified (yes/no).

Describe what the assessor observed in testing results to conclude that the vulnerabilities have been sufficiently mitigated.

Modified p. 106 → 103

~~(continued~~ on ~~next page) Identify the vendor evidence that details whether~~ third-party software, ~~platforms~~ or libraries ~~are used~~ for all or part of the random number generation ~~process.~~

Indicate whether the software relies on third-party software, platforms, or libraries for all or part of the random number generation process (yes/no).

Modified p. 106 → 104

Describe each of the software tests performed ~~to confirm that protection mechanisms have been implemented to mitigate~~ the ~~known vulnerabilities.~~

Describe each of the software tests performed in support of this test requirement, including the tool(s)/method(s) used and the scope of each test.

Removed p. 107

Identify the vendor evidence examined that details all of the methods implemented by the software to prevent or detect the interception or “hooking” of random number calls serviced from third- party software or from the software’s execution environment.

Describe each of the software tests performed to confirm the methods implemented by the software are consistent with the vendor evidence.

Modified p. 107 → 104

7.3.d The assessor shall examine vendor evidence and test the software to confirm that methods have been implemented to prevent or detect (and respond) the interception, or “hooking,” of random number calls that are serviced from third-party software, or the platform on which the software ~~application~~ is executed.

7.3.d The assessor shall examine vendor evidence and test the software to confirm that methods have been implemented to prevent or detect (and respond) the interception, or “hooking,” of random number calls that are serviced from third-party software, or the platform on which the software is executed.

Modified p. 107 → 105

Describe each of the tests performed in support of this test requirement, including how the assessor obtained ~~(at least)~~ 128MB of data output from each random number generator implemented by the software.

Describe each of the software tests performed in support of this test requirement, including the tool(s)/method(s) used and the scope of each test. Also describe how the assessor obtained at least 128MB of data output from each random number generator implemented by the software.

Modified p. 107 → 105

Describe what the assessor observed in the ~~testing~~ results ~~to conclude~~ that ~~there is reasonable assurance~~ that random number values cannot be statistically correlated.

Describe what the assessor observed in the documentation, evidence, and software test results that indicate that random number values cannot be statistically correlated.

Modified p. 107 → 105

Describe how the assessor confirmed that the methods used to generate the data output from the implemented random number ~~generators ensures~~ that the data is produced as it would be produced by the software during normal operation.

Describe how the assessor confirmed that the methods used to generate the data output from the implemented random number generation function(s) ensure that the data is produced as it would be produced by the software during normal operation.

Removed p. 108

Note: The assessor should refer to Control Objective 1 to identify all critical assets, including keys and other cryptographic material.

Identify the vendor evidence examined that details the methods used for the generation of all cryptographic keys and other key materials, and the effective strength requirements for all cryptographic primitives and keys.

Describe what the assessor observed in the vendor evidence and testing results to conclude that the methods used for generation of all cryptographic keys and other material have entropy that meets the minimum effective strength requirements of the cryptographic primitives and keys.

Modified p. 108 → 106

In Place N/A Not in Place 7.4.a The assessor shall examine vendor evidence and test the software to confirm that the methods used for the generation of all cryptographic keys and other material (such as IVs, “k” values for ~~DSS,~~ etc.) have entropy that meets the minimum effective strength requirements of the cryptographic primitives and keys.

In Place N/A Not in Place 7.4.a The assessor shall examine vendor evidence and test the software to confirm that the methods used for the generation of all cryptographic keys and other material (such as IVs, “k” values for digital signatures, etc.) have entropy that meets the minimum effective strength requirements of the cryptographic primitives and keys.

Modified p. 108 → 106

Describe each of the software tests performed ~~to confirm~~ the ~~methods implemented by~~ the ~~software for the generation~~ of ~~all cryptographic keys and other materials is consistent with the vendor evidence.~~

Describe each of the software tests performed in support of this test requirement, including the tool(s)/method(s) used and the scope of each test.

Removed p. 109

• Clear and sufficient guidance is provided in the vendor security guidance made available to stakeholders (per Control Objective 12) that any passphrase used must be:

Describe what the assessor observed in the vendor evidence and testing results to conclude that any methods used for generating keys directly from a password/passphrase provide sufficient entropy such that the total possible inputs are at least equal to that of the equivalent bit strength of the key being generated.

Modified p. 109 → 107

(continued on next page) Identify the ~~vendor~~ evidence examined ~~that details how cryptographic keys are generated by the software.~~

(continued on next page) Identify the documentation and evidence examined in support of this test requirement.

Modified p. 109 → 107

Indicate whether any cryptographic keys are generated through processes that require direct user interaction ~~with the application~~ (yes/no).

Indicate whether any cryptographic keys used by the software are generated through processes that require direct user interaction (yes/no).

Modified p. 109 → 107

Describe what the assessor observed in the ~~vendor evidence~~ and ~~testing~~ results ~~to conclude~~ that ~~the password/passphrase is~~ passed through an industry-standard ~~key-derivation~~ function ~~which~~ provides a work factor of at least ~~10,000.~~

Describe what the assessor observed in the documentation, evidence, and software test results that confirms that passwords/passphrases are passed through an industry-standard key- derivation function that provides a work factor of at least 10,000 for any attempt to brute-force the password/passphrase value.

Removed p. 110

Identify the vendor guidance examined, and the page(s) or section(s) within the guidance where stakeholders are instructed that passwords/passphrases must never be implemented in a way that violates requirements for split knowledge.

(continued on next page) Identify the vendor evidence examined that details whether third-party software or platforms are relied upon by the software for the generation of all cryptographic keys and other material, but do not meet entropy requirements.

Indicate whether sufficient entropy could not be provided per Test Requirement 7.4.a (yes/no).

Identify the vendor evidence examined that details the mitigations implemented to compensate for the lack of sufficient entropy.

Modified p. 110 → 108

Identify the ~~vendor~~ guidance ~~examined, and the page(s) or section(s) within the guidance where stakeholders are instructed to use~~ passwords/passphrases that are randomly generated using a valid and secure random process.

Identify the documentation and evidence that contains the software vendor’s guidance on using passwords/passphrases that are randomly generated using a valid and secure random process.

Removed p. 111

Identify the vendor guidance examined, and the page(s) or section(s) within the guidance where the secure configuration and usage of any such mitigations is covered.

Modified p. 111 → 109

Describe what the assessor observed in the ~~vendor evidence~~ and ~~testing~~ results ~~to conclude~~ that mitigations implemented ~~are sufficient~~ to compensate for the lack of sufficient entropy.

Describe what the assessor observed in the documentation, evidence, and software test results that confirms that appropriate mitigations are implemented to compensate for the lack of sufficient entropy.

Removed p. 112

Identify the vendor evidence examined that details all mechanisms used by the software to track all access and usage of critical assets.

Describe what the assessor observed in the vendor evidence and testing results to conclude that all access attempts and usage of critical assets are tracked and traceable to a unique identification for the person, system, or entity performing the access.

Modified p. 112 → 110

Describe each of the software tests performed ~~to confirm that~~ the ~~mechanisms implemented by~~ the ~~software to track all access and usage~~ of ~~critical assets are consistent with the vendor evidence.~~

Describe each of the software tests performed in support of this test requirement, including the tool(s)/method(s) used and the scope of each test.

Removed p. 113

Note: it is expected that a software test would be performed for each of the bulleted items in the test requirement.

Modified p. 113 → 111

• Disabling or deleting a security control or altering security functionality Identify the ~~vendor~~ evidence examined ~~that demonstrates that the tracking methods implemented track the specific activities defined within~~ this test requirement.

• Disabling or deleting a security control or altering security functionality Identify the documentation and evidence examined in support of this test requirement.

Modified p. 113 → 111

Describe each of the software tests performed ~~to confirm~~ the ~~tracking methods implemented are consistent with~~ the ~~vendor evidence.~~

Describe each of the software tests performed in support of this test requirement, including the tool(s)/method(s) used and the scope of each test.

Modified p. 113 → 112

• Details on what critical asset has been accessed Identify the ~~vendor~~ evidence examined ~~that demonstrates the tracking methods implemented capture, at a minimum, the information specified~~ in this test requirement.

• Details on what critical asset has been accessed Identify the documentation and evidence examined in support of this test requirement.

Modified p. 113 → 112

Describe each of the software tests performed ~~to confirm~~ the ~~tracking methods implemented capture information in a manner consistent with what was specified~~ the ~~vendor evidence.~~

Describe each of the software tests performed in support of this test requirement, including the tool(s)/method(s) used and the scope of each test.

Modified p. 114 → 112

Describe each of the software tests performed ~~to determine whether sensitive data is recorded~~ in ~~tracking data.~~

Describe each of the software tests performed in support of this test requirement, including the tool(s)/method(s) used and the scope of each test.

Modified p. 114 → 112

~~Describe what~~ the ~~assessor observed in the testing results that provides reasonable assurance~~ that sensitive data is not recorded in ~~activity~~ tracking data.

8.2.c The assessor shall test the software to confirm that sensitive data is not directly recorded in the tracking data.

Removed p. 115

Indicate whether the software manages the activity records (yes/no).

Summarize each of the protection methods implemented by the software to protect the completeness, accuracy and integrity of activity records.

Modified p. 115 → 113

~~Identify the vendor evidence examined that details~~ whether activity records are managed by the ~~software.~~

Indicate whether activity records are managed by the software (yes/no).

Modified p. 115 → 113

~~Identify the vendor evidence examined that details all of~~ the protection methods implemented to protect the ~~completeness, accuracy, and~~ integrity of ~~the~~ activity records.

Describe the protection methods implemented by the software to protect the integrity of activity records.

Modified p. 115 → 114

Describe each of the software tests performed ~~to confirm that that~~ the ~~protection mechanisms implemented by~~ the ~~software are consistent with the vendor evidence.~~

Describe each of the software tests performed in support of this test requirement, including the tool(s)/method(s) used and the scope of each test.

Removed p. 116

Indicate whether the software utilizes (or supports the use of) other systems for the maintenance of tracking data, such as a log server (yes/no).

Identify the vendor guidance examined, and the page(s) or section(s) within the guidance where the correct and complete setup and/or integration of such log storage system(s) is covered.

Describe what the assessor observed in the testing results to conclude that the methods implemented meet all applicable requirements of this standard.

Modified p. 116 → 114

The assessor shall test the software to confirm methods are implemented to secure the authenticity of the tracking data during transmission to the log storage system, and confirm that this protection meets the requirements of this ~~standard⎯for~~ example, authenticity parameters must be applied using strong ~~cryptography⎯and~~ any account or authentication parameters used for access to an external logging system are protected.

The assessor shall test the software to confirm methods are implemented to secure the authenticity of the tracking data during transmission to the log storage system, and to confirm that this protection meets the requirements of this standard

•for example, authenticity parameters must be applied using strong cryptography

•and any account or authentication parameters used for access to an external logging system are protected.

Modified p. 116 → 114

~~Identify the vendor evidence examined that details~~ whether the software ~~utilizes~~ other systems for maintaining tracking ~~data.~~

Indicate whether the software uses or supports the use of other systems for storing or maintaining activity tracking data (yes/no).

Modified p. 116 → 114

Describe ~~each of the software tests performed to identify~~ the methods implemented by the software to secure the authenticity of tracking data during transmission to ~~the~~ log storage system(s).

Describe the methods implemented by the software to secure the authenticity of activity tracking data during transmission to third-party or external activity tracking or log storage system(s).

Removed p. 117

(continued on next page) Identify the vendor evidence examined that details how the software protects the integrity of activity tracking records, and confirms those methods are implemented in a manner consistent with this test requirement.

Describe each of the software tests performed to confirm the methods implemented by the software are consistent with the vendor guidance and this test requirement.

Describe what the assessor observed in the vendor evidence and testing results to conclude that the software does not overwrite any tracking data upon a restart of the software, and each new start only appends to existing datasets or creates a new tracking dataset.

Indicate whether unique dataset names are relied upon for maintaining the integrity between execution instances (yes/no).

If “yes,” describe what the assessor observed in the vendor evidence and testing results to conclude that no another application (or instance of the same application) can overwrite or render invalid any existing data …

Modified p. 117 → 115

• The software does not overwrite existing tracking data upon a restart of the software. Each new start shall only append to existing ~~datasets,~~ or create a new tracking dataset.

• The software does not overwrite existing tracking data upon a restart of the software. Each new start shall only append to existing datasets or shall create a new tracking dataset.

Modified p. 117 → 115

• Where unique dataset names are relied upon for maintaining integrity between execution instances, the implementation ensures that ~~another application~~ (including another instance of the same ~~application)~~ cannot overwrite or render invalid existing datasets.

• Where unique dataset names are relied upon for maintaining integrity between execution instances, the implementation ensures that other software (including another instance of the same software) cannot overwrite or render invalid existing datasets.

Removed p. 118

Indicate whether conditions exist where it is not possible for the software to apply file privileges to assist with maintaining the integrity of the activity tracking data set (yes/no).

If “no,” describe what the assessor observed in the vendor evidence and testing results to conclude that the software applies suitable file privileges to assist with maintaining the integrity of the tracking dataset.

If “yes,” describe the vendor’s justification for why such file privileges could not be applied.

If “yes,” identify the additional mitigations implemented to maintain the integrity of the tracking data.

Identify the software tests specified in this test requirement that could not be performed.

For each of the software tests not performed, identify the individuals interviewed that confirm the vendor maintains reasonable justification to describe why this is the case.

For each of the software tests not performed, describe the vendor’s justification for why they could not be performed.

For each of the software tests …

Modified p. 119 → 116

Where any of the tests above are not possible, the assessor shall interview personnel to confirm reasonable justification exists to describe why this is the ~~case,~~ and shall confirm protections are put in place to prevent such scenarios from affecting the integrity of the tracking records.

Where any of the tests above are not possible, the assessor shall interview personnel to confirm reasonable justification exists to describe why this is the case and shall confirm protections are put in place to prevent such scenarios from affecting the integrity of the tracking records.

Modified p. 119 → 116

~~(continued on next page)~~ Describe ~~how~~ each of the software tests ~~defined~~ in this test ~~requirement were performed~~ and the ~~results~~ of each test.

Describe each of the software tests performed in support of this test requirement, including the tool(s)/method(s) used and the scope of each test.

Modified p. 119 → 116

Indicate whether any of the tests specified in this test requirement could not be performed (yes/no).

Indicate whether any of the tests specified in this test requirement could not be performed or did not produce the expected result (yes/no).

Removed p. 121

Note: The assessor should refer to Control Objective 4 for information on the possible attack scenarios and mitigation controls implemented by the software vendor.

(continued on next page) Identify the vendor evidence examined that details the methods implemented by the software to validate the integrity of its own executable and any configuration options, files or datasets the software relies upon for operation.

Identify the vendor evidence and publicly-available literature examined that confirms there are no methods made available by the platform for validating the integrity/authenticity of the software executables, configuration files, and datasets.

Modified p. 121 → 117

Where the execution environment prevents this, the assessor shall examine vendor evidence and current publicly available literature on the platform and associated technologies to confirm that there are indeed no methods for validating ~~authenticity, and~~ shall test the software to confirm controls are implemented to minimize the associated risk.

Where the execution environment prevents this, the assessor shall examine vendor evidence and current publicly available literature on the platform and associated technologies to confirm that there are indeed no methods for validating authenticity. The assessor shall then test the software to confirm controls are implemented to minimize the associated risk.

Modified p. 121 → 117

Describe each of the software tests performed ~~to confirm~~ the ~~methods implemented by~~ the ~~software are consistent with the vendor evidence, and ensure unauthorized, post-deployment changes are detected.~~

Describe each of the software tests performed in support of this test requirement, including the tool(s)/method(s) used and the scope of each test.

Modified p. 121 → 117

Indicate whether the execution environment ~~prevents~~ the software from validating the integrity of its own ~~executable and any configuration options, files, and datasets that it relies upon for operation~~ (yes/no).

Indicate whether the execution environment or other factors prevent the software from validating the integrity of its own files (yes/no).

Removed p. 122

Describe the frequency with which integrity values used by the software and dataset(s) upon which the software relies upon for secure operation are checked.

Modified p. 122 → 118

9.1.b The assessor shall examine vendor evidence and test the software to confirm that integrity values used by the ~~application~~ and dataset(s) upon which it relies for secure operation are checked upon ~~execution of the application,~~ and at least every 36 hours thereafter (if the software continues execution during that time period). The assessor shall confirm what action the software takes upon failure of these checks and confirm that the processing of sensitive data is halted until this problem is …

9.1.b The assessor shall examine vendor evidence and test the software to confirm that integrity values used by the software and dataset(s) upon which it relies for secure operation are checked upon software execution, and at least every 36 hours thereafter (if the software continues execution during that time period). The assessor shall confirm what action the software takes upon failure of these checks and confirm that the processing of sensitive data is halted until this problem is remediated.

Modified p. 122 → 118

~~Identify~~ the ~~vendor evidence examined that demonstrates how the software checks~~ integrity values used by the software and ~~the datasets~~ upon which the software relies for ~~its~~ secure ~~operation in a manner consistent with this test requirement.~~

Describe the frequency with which integrity values used by the software and dataset(s), upon which the software relies upon for secure operation, are checked.

Modified p. 122 → 118

Describe the ~~action~~ the software takes upon the failure of such integrity checks.

Describe the actions the software takes upon the failure of such integrity checks.

Modified p. 122 → 119

Describe each of the software tests performed ~~to confirm the software checks implemented by the software are consistent with~~ this test ~~requirement~~ and the ~~vendor evidence.~~

Describe each of the software tests performed in support of this test requirement, including the tool(s)/method(s) used and the scope of each test.

Removed p. 123

Note: The assessor should refer to Control Objective 7 for information on appropriate and correct usage of cryptography.

Indicate whether cryptographic primitives are used by the software for anomaly-detection (yes/no).

Identify the vendor evidence examined that details how cryptographic primitives are protected.

Modified p. 123 → 118

Describe what the assessor observed in the ~~vendor evidence~~ and testing results ~~to conclude~~ that the ~~protection mechanisms implemented are appropriate for protecting~~ cryptographic primitives

Describe what the assessor observed in the documentation, evidence, and software testing results that confirms whether the software uses cryptographic primitives to detect anomalies.

Modified p. 123 → 119

~~Identify the vendor evidence examined that details~~ whether ~~cryptographic primitives~~ are used by the software for ~~anomaly-detection.~~

Indicate whether stored values are used by the software for to detect anomalies (yes/no).

Modified p. 123 → 120

Describe each of the software tests performed ~~to confirm~~ the ~~protection mechanisms implemented are consistent with~~ the ~~vendor evidence.~~

Describe each of the software tests performed in support of this test requirement, including the tool(s)/method(s) used and the scope of each test.

Removed p. 124

If “no,” skip to 9.1.e.

Removed p. 124

Note: The assessor should refer to Control Objective 1 and 6 to identify all critical assets and implemented security controls.

Indicate whether stored values are used by the software for anomaly-detection (yes/no).

Describe each of the software tests performed confirm the protection mechanisms implemented are consistent with the vendor evidence.

Describe what the assessor observed in the vendor evidence and testing results to conclude that the protection mechanisms implemented are appropriate to protect the stored values are appropriately protected.

Modified p. 124 → 118

Identify the ~~vendor~~ evidence examined ~~that details how stored values are protected.~~

Identify the documentation and evidence examined for this test requirement.

Modified p. 124 → 119

~~Identify~~ the ~~vendor~~ evidence ~~examined~~ that ~~details~~ whether stored values are used by the software ~~for anomaly- detection.~~

Describe what the assessor observed in the documentation and evidence that confirms whether stored values are used by the software to detect anomalies.

Removed p. 125

Identify the vendor evidence examined that details whether configuration or other dataset values are modified by the software during execution.

Describe how the integrity protections are implemented in a way that allow for updates during execution while still ensuring the integrity of the values can be validated after update.

Modified p. 125 → 120

~~Identify the vendor evidence examined that details~~ the integrity protections implemented to protect configuration or other dataset ~~values.~~

Describe the integrity protections implemented to protect configuration or other dataset values from modification during software execution.

Modified p. 125 → 121

Describe each of the software tests performed ~~to confirm that~~ the ~~integrity protections are implemented in a manner consistent with~~ the ~~vendor evidence.~~

Describe each of the software tests performed in support of this test requirement, including the tools(s)/method(s) used and the scope of each test.

Removed p. 126

Identify the vendor evidence examined that details the controls implemented by the software to prevent brute-force attacks on account, password, or cryptographic-key input fields.

Describe each of the software tests performed to confirm the controls implemented by the software are consistent with the vendor evidence.

Modified p. 126 → 121

Describe what the assessor observed in the ~~vendor evidence~~ and ~~testing~~ results ~~to conclude~~ that ~~the~~ controls implemented ~~are appropriate~~ to prevent brute-force attacks on account, password, or cryptographic-key input ~~fields.~~

Describe what the assessor observed in the documentation, evidence, and software test results that confirms that controls are implemented to prevent brute-force attacks on account, password, or cryptographic-key input fields, and that the controls are appropriate for their intended purpose.

Removed p. 127

(continued on next page) Identify the vendor evidence examined that the controls implemented by the software to mitigate each of the attacks identified in Test Requirement 10.1.a.

Modified p. 127 → 122

Identify the ~~vendor~~ evidence examined that ~~details all common~~ attack methods applicable to the software.

Identify the documentation and evidence examined that identifies and describes the attack methods applicable to the software.

Modified p. 127 → 122

10.1.b The assessor shall examine vendor evidence to confirm that the list of common attacks is valid for the software the vendor has ~~produced,~~ and note where this does not include common attack methods detailed in industry- standard references such as OWASP and CWE lists.

10.1.b The assessor shall examine vendor evidence to confirm that the list of common attacks is valid for the software the vendor has produced and shall note where this does not include common attack methods detailed in industry- standard references such as OWASP and CWE lists.

Modified p. 127 → 122

Describe what the assessor observed in the ~~vendor~~ evidence examined in ~~Test Requirement~~ 10.1.a ~~to conclude~~ that the vendor has reasonably ~~considered the susceptibility~~ of the software to ~~common attack methods.~~

Describe what the assessor observed in the documentation and evidence examined in 10.1.a that indicates that the software vendor has conducted a reasonably comprehensive assessment of the common software attack methods applicable to the software and the software’s susceptibility to them.

Modified p. 127 → 123

Describe what the assessor observed in the ~~vendor~~ evidence ~~to conclude~~ that ~~protection mechanisms~~ are ~~appropriate for mitigating each of~~ the ~~attacks identified in Test Requirement 10.1.a.~~

Describe what the assessor observed in the documentation and evidence that confirms that such processes are implemented throughout the entire software lifecycle.

Removed p. 129

Note: The assessor should refer to Control Objective 4 for information on the possible attack scenarios and mitigation controls implemented by the software vendor.

Summarize the testing processes implemented by the vendor to validate the mitigations used to secure the software against attacks.

Describe what the assessor observed in the vendor evidence to conclude that such processes are performed throughout the entire software lifecycle.

(continued on next page) Identify the vendor evidence examined that confirms the findings for this test requirement.

Identify the automated tools used as part of the vendor’s testing process to detect vulnerabilities in software code and during execution in accordance with this test requirement.

Describe what the assessor observed in the vendor evidence to conclude that the vendor’s testing process accounts for the entire code base, including third-party, open-source, or shared components and libraries.

Modified p. 129 → 124

• Includes, at a minimum, the use of automated tools capable of detecting vulnerabilities both in software code and during software execution, and that the tools 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.

• Includes, at a minimum, the use of automated tools capable of detecting vulnerabilities both in software code and during software execution.

Modified p. 130 → 124

Describe what the assessor observed in the ~~vendor~~ evidence ~~to conclude~~ that the vendor’s testing process accounts for common vulnerabilities and attack ~~methods.~~

Describe what the assessor observed in the documentation and evidence that indicates that the software vendor’s testing process reasonably accounts for all common vulnerabilities and attack methods applicable to the software.

Modified p. 130 → 124

Describe what the assessor observed in the ~~vendor~~ evidence ~~to conclude~~ that the vendor’s testing process demonstrates a history of finding software vulnerabilities and remediating them prior to ~~retesting of the software.~~

Describe what the assessor observed in the documentation and evidence that confirms that the software vendor’s testing process demonstrates a history of successfully finding software vulnerabilities and remediating them prior to software release.

Modified p. 130 → 125

• For all vulnerabilities, the vendor provides a remediation ~~plan⎯it~~ is unacceptable for a known vulnerability to remain unmitigated for an indefinite period.

• For all vulnerabilities, the vendor provides a remediation plan

•it is unacceptable for a known vulnerability to remain unmitigated for an indefinite period.

Modified p. 130 → 125

~~Describe~~ the vendor’s vulnerability ranking/categorization scheme and how it aligns with other industry-standard schemes.

Summarize the software vendor’s vulnerability ranking/categorization scheme and how it aligns with other industry-standard schemes.

Modified p. 130 → 125

Describe the vendor’s process ~~for ensuring~~ vulnerabilities do not remain unmitigated indefinitely.

Describe how the software vendor’s process ensures vulnerabilities do not remain unmitigated indefinitely.

Modified p. 131 → 126

~~Describe~~ the vendor’s criteria for how ~~(and~~ how ~~often)~~ the vendor releases software updates to fix security ~~vulnerabilities and why the assessor considers the criteria reasonable.~~

Summarize the software vendor’s criteria for how and how often the vendor releases software updates to fix security vulnerabilities.

Modified p. 131 → 127

~~(continued on next page)~~ Identify the ~~vendor~~ software ~~updates sampled for~~ this test requirement.

Identify the software update sample selected in support of this test requirement.

Modified p. 131 → 127

Identify the ~~vendor~~ evidence ~~examined, including update-specific security testing results and details, that confirm the findings for~~ this requirement.

Identify the documentation and evidence examined in support of this requirement.

Modified p. 131 → 127

Indicate whether any evidence was obtained that ~~demonstrates~~ the vendor did not provide security fixes to stakeholders in accordance with its defined criteria (yes/no).

Indicate whether any evidence was obtained that suggests the software vendor did not provide security fixes to stakeholders in accordance with its own defined criteria (yes/no).

Modified p. 131 → 129

Describe what the assessor observed in the vendor ~~evidence to conclude the vendor makes~~ security updates ~~available to stakeholders in accordance with its defined criteria.~~

Describe what the assessor observed in the documentation and evidence that confirms that the software vendor informs uses and other stakeholders when security updates are available.

Removed p. 133

Identify the vendor evidence examined that details how software updates are released in a manner that protects the integrity of the software code during transmission and install.

If “no,” skip to 11.2.b.

Identify the vendor guidance examined, and the page(s) or section(s) within the guidance where instructions are provided to guide users through this process.

Modified p. 133 → 128

In Place N/A Not in Place 11.2.a The assessor shall examine vendor evidence to confirm that the method by which the vendor releases software updates ensures the integrity of the software and its code during transmission and install. Where user instructions are required to validate the integrity of the code, the assessor shall confirm that clear and sufficient guidance to enable the process to be correctly performed is provided in the ~~vendor security~~ guidance made available to stakeholders ~~(per~~ Control …

In Place N/A Not in Place 11.2.a The assessor shall examine vendor evidence to confirm that the method by which the vendor releases software updates ensures the integrity of the software and its code during transmission and install. Where user instructions are required to validate the integrity of the code, the assessor shall confirm that clear and sufficient guidance to enable the process to be correctly performed is provided in the software vendor’s implementation guidance made available to stakeholders per …

Modified p. 133 → 128

Indicate whether the software requires user interaction to validate the integrity of the code (yes/no).

Indicate whether the software requires user interaction to validate the integrity of the software update code (yes/no).

Modified p. 133 → 129

Describe what the assessor observed in the ~~vendor~~ evidence ~~to conclude~~ that ~~the vendor’s methods for delivering software updates are appropriate to protect the integrity of~~ the software ~~and its code during transmission, and installation or implementation.~~

Describe what the assessor observed in the documentation and evidence that confirms whether the software provides software integrity validation methods that are cryptographically insecure.

Removed p. 134

Indicate whether the methods to protect the integrity of update code are cryptographically secure (yes/no).

If “yes,” describe what the assessor observed in the vendor evidence to conclude integrity methods are cryptographically secure.

Identify the vendor evidence examined that that demonstrates the vendor informs users (and other stakeholders) of the availability software updates.

Identify the page(s) or section(s) within the vendor guidance where the appropriate acquisition, and installation or implementation of software updates is covered.

Modified p. 134 → 129

~~Identify~~ the ~~vendor evidence examined that details whether~~ methods to protect the integrity of update code are ~~not~~ cryptographically ~~secure.~~

Indicate whether the methods to protect the integrity of software update code are cryptographically insecure (yes/no).

Modified p. 134 → 129

If ~~“no,”~~ describe how the ~~vendor~~ evidence ~~examined~~ demonstrates that the software distribution methods provide a suitable chain of trust.

If “yes,” describe how the documentation and evidence demonstrates that the software distribution methods provide a suitable chain of trust.

Modified p. 134 → 129

11.2.c The assessor shall examine vendor evidence to confirm that the vendor informs users of the software ~~updates~~ and ~~provides~~ clear and sufficient guidance on how they may be obtained and installed ~~(per~~ Control Objective ~~12).~~

11.2.c The assessor shall examine vendor evidence to confirm that the software vendor informs users of the software updates, and that clear and sufficient guidance on how they may be obtained and installed is provided in the software vendor’s implementation guidance made available to stakeholders per Control Objective 12.1.

Modified p. 134 → 129

Identify the ~~vendor~~ evidence ~~examined~~ that ~~demonstrates~~ the ~~vendor provides~~ guidance on how ~~software updates should be obtained~~ and ~~installed, in accordance with Control Objective 12.~~

Identify the documentation and evidence that contains the software vendor’s guidance on how to obtain and install security updates.

Removed p. 135

Identify the vendor evidence examined that details the vendor’s process for notifying users when known vulnerabilities in the software have been identified but not yet patched in the software.

Describe what the assessor observed in the vendor evidence to conclude that the vendor’s process includes methods to provide users with mitigation techniques for unpatched vulnerabilities until a security patch can be provided.

Modified p. 135 → 130

Describe what the assessor observed in the ~~vendor~~ evidence ~~to conclude~~ that the vendor’s update mechanisms cover all software, configuration files, and metadata used by the software for security purposes or could affect the security of the software.

Describe what the assessor observed in the documentation and evidence that confirms that the software vendor’s update mechanisms cover all software, configuration files, and metadata used by the software for security purposes or could affect the security of the software.

Removed p. 136

Identify the vendor evidence examined that details the vendor’s process for providing stakeholders guidance on the secure installation and use of the software.

Identify the vendor guidance examined, and the page(s) or section(s) within the guidance where instructions for the proper configuration of the platform(s) on which the software will be executed are provided.

Identify the vendor guidance examined, and the page(s) or section(s) within the guidance where instructions for the proper management of cryptographic keys are covered.

Modified p. 136 → 132

• Includes instructions for key management (e.g., use of keys, how keys are distributed, loaded, removed, changed, destroyed, etc.) (continued on next page) Identify the vendor guidance examined, and the page(s) or section(s) within the guidance where the installation or implementation of any third-party software required for software operation is covered.

• Includes instructions for key management (e.g., use of keys, how keys are distributed, loaded, removed, changed, destroyed, etc.)

Removed p. 137

Identify the vendor guidance examined, and the page(s) or section(s) within the guidance where instructions on how to validate the version of the software and details on the version of the software the guidance applies to are covered.

Describe what the assessor observed in vendor evidence to conclude that the vendor provides justification(s) for all requirements within this standard deemed not applicable, and why the assessor considers each of the justification(s) reasonable.

Modified p. 137 → 132

• Provides justification for any requirements in this standard that are to be assessed as not applicable. For each of these, the assessor shall confirm reasonable justification exists for why this is the ~~case,~~ and confirm that it agrees with their understanding and the results of their testing of the software.

• Provides justification for any requirements in this standard that are to be assessed as not applicable. For each of these, the assessor shall confirm reasonable justification exists for why this is the case and confirm that it agrees with their understanding and the results of their testing of the software.

Modified p. 137 → 132

Describe what the assessor observed in the ~~vendor guidance to reasonably conclude~~ that users are ~~not~~ instructed to disable security settings or parameters ~~within~~ the installed environment ~~to facilitate~~ software operation.

Describe what the assessor observed in the documentation and evidence that confirms that users are never instructed to disable security settings or parameters in the installed environment that support software operation.

Modified p. 137 → 132

Describe what the assessor observed in the ~~vendor~~ guidance to ~~reasonably conclude that users are not instructed to execute~~ the software ~~in a privileged mode higher than the minimum privileges necessary for software operation.~~

Describe what the assessor observed in the documentation and evidence that confirms that the guidance provided to stakeholders clearly identifies the version(s) of the software to which it applies.

Removed p. 138

Identify the vendor evidence examined (as identified in the testing of Control Objective 1) that details all locations within the software (or its execution environment) where sensitive data is stored (both persistently and temporarily).

Note: If the software does store sensitive authentication data after authorization, then A.1.1.b must be completed.

Modified p. 138 → 133

A.1.1 The software does not store sensitive authentication data after ~~authorization⎯even~~ if ~~encrypted⎯unless the software is intended only for use by issuers or organizations that support issuing services.~~

A.1.1 The software does not store sensitive authentication data after authorization

•even if encrypted

Modified p. 138 → 133

Describe each of the software tests performed ~~identify all locations within~~ the ~~software (or its execution environment) where sensitive data is stored.~~

Describe each of the software tests performed in support of this test requirement, including the tool(s) or method(s) used and the scope of each test.

Modified p. 138 → 133

Describe what the assessor observed in the test results ~~(and vendor evidence)~~ that ~~provides reasonable assurance~~ the software ~~does not store~~ sensitive authentication data after authorization.

Describe what the assessor observed in the documentation, evidence, and software test results that confirms whether the software stores sensitive authentication data after authorization.

Removed p. 139

Indicate whether the testing in A.1.1.a determined the software stores sensitive data after authorization (yes/no).

If “no,” skip to A.2.1.

Modified p. 139 → 133

~~Identify~~ the ~~vendor~~ evidence ~~examined~~ that ~~demonstrates~~ the software is intended only for use by issuers or organizations that support issuing services.

If “yes,” Describe what the assessor observed in the documentation and evidence that indicates that the software is intended only for use by issuers or organizations that support issuing services.

Removed p. 140

Identify the vendor evidence examined that demonstrates the vendor provides stakeholders guidance consistent with this test requirement.

Identify the vendor guidance and the page(s) or section(s) within the guidance that details the locations where the software stores cardholder data.

Identify the vendor guidance and the page(s) or section(s) within the guidance where instructions on how to securely delete cardholder data stored by the software are provided.

Identify the vendor guidance and the page(s) or section(s) within the guidance where instructions for configuring the underlying software or systems to prevent inadvertent capture or retention of cardholder data are provided.

Modified p. 140 → 134

In Place N/A Not in Place ~~A.2.1.a~~ The assessor shall examine the instructions prepared by the software vendor and confirm the documentation includes the following guidance for customers, ~~integrators~~ and resellers:

In Place N/A Not in Place A.2.1 The assessor shall examine the instructions prepared by the software vendor and confirm the documentation includes the following guidance for customers, integrators, and resellers:

Modified p. 140 → 134

• Instructions on how to securely delete cardholder data stored by the payment ~~application,~~ including data stored on underlying software or systems (such as OS, databases, etc.).

• Instructions on how to securely delete cardholder data stored by the payment software, including data stored on underlying software or systems (such as OS, databases, etc.).

Removed p. 141

Identify the vendor guidance, and the page(s) or section(s) within the guidance where all instances where PAN is displayed within the software (or its execution environment) are detailed.

Identify the vendor guidance, and the page(s) or section(s) within the guidance where customers and integrators/resellers are instructed that all displays of PAN must be masked to a maximum of the first six and last four digits by default.

If “yes,” identify the vendor guidance examined, and the page(s) or section(s) within the guidance where instructions for how to properly configure the software to display more than the first six and last four digits of the PAN are provided.

Note: If “yes,” A.2.2.c applies as well.

Modified p. 141 → 135

In Place N/A Not in Place A.2.2.a The assessor shall examine vendor evidence, including ~~security~~ guidance made available to stakeholders ~~(per~~ Control Objective ~~12),~~ to confirm the guidance includes the following instructions for customers and integrators/resellers:

In Place N/A Not in Place A.2.2.a The assessor shall examine vendor evidence, including the software vendor’s implementation guidance made available to stakeholders per Control Objective 12.1, to confirm the guidance includes the following instructions for customers and integrators/resellers:

Modified p. 141 → 135

Identify the ~~vendor~~ evidence examined ~~that confirms the vendor provides guidance to stakeholders~~ in ~~a manner consistent with~~ this test requirement.

Identify the documentation and evidence examined in support of this test requirement.

Modified p. 141 → 135

~~Indicate~~ whether the software supports the display of ~~full~~ PAN (yes/no).

Based on the documentation and evidence, indicate whether the software supports the full display of PAN (yes/no).

Removed p. 142

Note: This test requirement is only applicable where the software supports the display of the full PAN.

Describe what the assessor observed in the vendor evidence (examined in Test Requirement A.2.2.a) and the testing results to conclude that the instructions provided in the vendor guidance for displaying more that the first six/last four digits are accurate.

Modified p. 142 → 136

Describe each of the software tests performed ~~to identify all locations within~~ the ~~software where PAN is displayed.~~

Describe each of the software tests performed in support of this test requirement, including the tool(s) or method(s) used and the scope of each test.

Modified p. 142 → 136

Describe what the assessor observed in the ~~testing~~ results ~~to conclude~~ that all displays of PAN are masked to a maximum of the first six and last four digits by default.

Describe what the assessor observed in the documentation, evidence, and software test results that indicates that all displays of PAN are masked to a maximum of the first six and last four digits by default.

Modified p. 142 → 136

Describe each of the software tests performed ~~to determine whether~~ the ~~guidance provided in Test Requirement A.2.2.a on properly configuring~~ the ~~software to display more than the first six/last four digits is accurate.~~

Describe each of the software tests performed in support of this test requirement, including the tool(s) or method(s) used and the scope of each test.

Removed p. 143

(continued on next page) Identify the vendor evidence examined that confirms the vendor provides security guidance to stakeholders in a manner consistent with this test requirement.

Identify the vendor guidance examined, and the page(s) or section(s) within the guidance where instructions for properly configuring all available options to render cardholder data unreadable are provided.

Identify the vendor guidance examined, and the page(s) or section(s) within the guidance that details all instances where cardholder data is output for the purposes of storing outside of the payment software.

Modified p. 143 → 137

In Place N/A Not in Place A.2.3.a The assessor shall examine vendor evidence, including the ~~security~~ guidance made available to stakeholders ~~(per~~ Control Objective ~~12)~~ to verify the guidance includes the following:

In Place N/A Not in Place A.2.3.a The assessor shall examine vendor evidence, including the software vendor’s implementation guidance made available to stakeholders per Control Objective 12.1 to verify the guidance includes the following:

Modified p. 143 → 137

• Details of any configurable options for each method used by the software to render cardholder data unreadable, and instructions on how to configure each method for all locations where cardholder data is stored by the payment ~~application (per as identified in Control Objective A.2.1).~~

• Details of any configurable options for each method used by the software to render cardholder data unreadable, and instructions on how to configure each method for all locations where cardholder data is stored by the payment software.

Removed p. 144

Identify the vendor guidance examined, and the page(s) or section(s) within the guidance where instructions are provided to remind users that they are responsible for rendering PAN unreadable wherever it is output for the purposes of storing outside of the payment software.

Identify the vendor guidance examined, and the page(s) or section(s) within the guidance where instructions are provided to remind users that wherever debugging logs are enabled that might include PAN, that the debugging logs must be protected from authorized access, disabled as soon as troubleshooting is complete, and securely deleted when no longer needed.

Modified p. 144 → 138

Describe each of the software tests performed ~~to confirm the methods implemented by the software to protect PAN are consistent with the vendor evidence and~~ this test ~~requirement.~~

Describe each of the software tests performed in support of this test requirement, including the tool(s) or method(s) used and the scope of each test.

Modified p. 144 → 138

Describe what the assessor observed in the ~~vendor evidence~~ and ~~testing~~ results ~~to conclude~~ that PAN is rendered unreadable wherever it is stored persistently.

Describe what the assessor observed in the documentation, evidence, and software test results that confirms that PAN is rendered unreadable wherever it is stored persistently.

Modified p. 144 → 142

Identify the ~~vendor~~ evidence examined that ~~details all methods used to protect PAN during persistent storage.~~

Identify the documentation and evidence examined that identifies and describes the locations where sensitive data is stored.

Modified p. 145 → 138

~~Identify~~ the ~~vendor evidence examined~~ that ~~details~~ whether the software creates both tokenized and truncated versions of the same PAN.

Describe what the assessor observed in the documentation, evidence, and software test results that confirms whether the software creates both tokenized and truncated versions of the same PAN.

Modified p. 145 → 139

Describe each of the software tests performed ~~to try~~ and ~~correlate~~ the ~~tokenized and truncated versions~~ of ~~the PAN to reconstruct the original PAN.~~

Describe each of the software tests performed in support of this test requirement, including the tool(s) or method(s) used and the scope of each test.

Modified p. 145 → 146

Indicate whether the software ~~creates both tokenized and truncated versions of the same PAN~~ (yes/no).

Indicate whether the software supports external communications (yes/no).

Modified p. 145 → 146

If “no,” skip to ~~A.2.3.d.~~

If “no,” skip to B.2.3.

Modified p. 145 → 169

Describe what the assessor observed in the ~~vendor evidence and~~ testing results that ~~provides reasonable assurance~~ that ~~tokenized and truncated versions of the PAN cannot be correlated to reconstruct the original PAN.~~

Describe what the assessor observed in the software testing results that confirms that sensitive data is not exposed or inadvertently leaked through error codes or messages.

Modified p. 146 → 139

~~Identify~~ the ~~vendor evidence examined~~ that ~~details~~ whether the software ~~creates or~~ generates files for use outside of the software.

Describe what the assessor observed in the documentation, evidence, and software test results that confirms whether the software generates files for use outside of the software.

Modified p. 146 → 140

Describe each of the software tests performed ~~to determine whether PAN is rendered unreadable anywhere it is output by~~ the ~~software.~~

Describe each of the software tests performed in support of this test requirement, including the tool(s) or method(s) used and the scope of each test.

Modified p. 146 → 140

If “yes,” describe what the assessor observed in the ~~vendor evidence~~ and ~~testing~~ results ~~to conclude~~ that ~~all~~ PAN stored on vendor ~~systems is rendered unreadable.~~

If “yes,” describe what the assessor observed in the documentation, evidence, and software test results that confirms that PAN is rendered unreadable wherever and whenever it is stored on vendor systems.

Modified p. 146 → 141

Describe what the assessor observed in the ~~vendor~~ evidence ~~and testing results~~ to conclude that ~~PAN is rendered unreadable wherever it is output outside of~~ the ~~software.~~

Describe what the assessor observed in the documentation and evidence to conclude that all UI’s and APIs provided or made accessible by the software are documented.

Modified p. 146

Identify the ~~vendor~~ evidence examined that ~~details~~ whether the ~~vendor stores PAN on vendor systems for any reason.~~

Identify the documentation and evidence examined that confirms whether the software supports external communications.

Modified p. 146 → 148

If “no,” skip to ~~A.2.3.e.~~

If “no,” skip to B.2.3.

Modified p. 146 → 150

Indicate whether the software ~~vendor stores PAN on vendor systems for any reason~~ (yes/no).

Indicate whether the software supports the encryption of sensitive data (yes/no).

Modified p. 146 → 157

Indicate whether the software ~~creates~~ or ~~generates files for use outside~~ the ~~software~~ (yes/no).

Indicate whether the software connects to or uses any shared resources provided by the payment terminal (yes/no).

Modified p. 146 → 158

~~If “yes,” describe~~ each of the software tests performed in support of this test ~~requirement.~~

Describe each of the software tests performed in support of this test requirement, including the tool(s) or method(s) used and the scope of each test.

Modified p. 148 → 179

B.1 Confirmation of Testing Environment Used The Secure Software Assessor Company’s Testing Environment, as describe in Section ~~5.5.1~~ of the Secure Software Program Guide, was used for this assessment.

B.1 Confirmation of Testing Environment Used The Secure Software Assessor Company’s Testing Environment, as describe in Section 4.5.1 of the Secure Software Program Guide, was used for this assessment.

Modified p. 148 → 179

Note: If ~~“No,”~~ then provide reasons why the Secure Software Assessor Company Test Environment is not capable of properly and fully testing all functions of the Payment Software and describe the alternative environment(s) used in the field below:

Note: If “no,” then provide reasons why the Secure Software Assessor Company Test Environment is not capable of properly and fully testing all functions of the Payment Software and describe the alternative environment(s) used in the field below:

Document Comparison

From Revision History

Content Changes