Caveat: This isn’t a post about which Self-Assessment Questionnaire SAQ you should use. You can confirm that by speaking with your acquiring bank. Confide can assist in these conversations and give our opinion on what SAQ we believe is correct, but your acquiring bank will make the final decision.

There are a lot of acronyms that get used in relation to payments: RoC, AoC, SAQ, P2PE, PTS, PA-DSS and of course PCI DSS.

This article focuses on distinguishing some of the different types of reports that are used to demonstrate PCI compliance.

What Determines What Report I Can Use?

Short Answer: The bank.

Longer Answer: The bank will review the number of transactions that you do each year and the payment channels that you support. They may also review whether they consider you as a service provider or whether you fit the definition of a payment aggregator or facilitator. Based on this, they may direct you to a QSA to review your payment channels and provide advice or they may already have an expectation around what reporting you need to provide.

Transaction Volumes

Let’s start with transaction volume, since that is one of the first things which will help determine whether you can self-assess or whether you need a full Report on Compliance (RoC). Merchants and service providers have different thresholds for the number of transactions which will require a particular report type.

Merchant Transaction Volume

[table id=1 /]

Service Provider Transaction Volumes

[table id=2 /]

It is worth noting though that even if you do not meet the transaction volume for a Report on Compliance, the bank, the card brands, or even your customers might require it.

Self-Assessment Questionnaires (SAQ)

As of 2020, PCI has nine different SAQs that apply to different payment channels, methods of transactions, and type of entity (merchant or service provider). These are summarised below.

[table id=3 /]

Each SAQ has a set of criteria to use it. You have to be able to attest that you meet all of the criteria in order to use that particular SAQ. Every SAQ other than SAQ D requires you to attest that you do not store any cardholder data. One way to prove this is to use a data discovery tool to find unprotected credit cards.

The only SAQ that service providers are allowed to use if they do not meet the threshold for a full Report on Compliance is SAQ D for Service Providers. If a service provider gives you an AoC using any other SAQ, they have not assessed as a service provider.

Merchants are able to use any of the other eight SAQs depending on the payment channels. When there are multiple payment channels, the bank may ask you to submit SAQ D to cover all your payment channels or they may accept multiple SAQs. Every SAQ other than SAQ D requires to attest that the payment channel described is your only payment channel. Because of this, SAQ D is usually the most appropriate. You should always check with your bank if you have multiple payment channels.

The self-assessment questionnaires (SAQs) are a shortened version of the full standard reduced to the minimum controls that must be in place for that payment channel. However, just because the other requirements are not included in the SAQ does not mean that they do not have to be met. A key takeaway from PCI is that every requirement must be met by at least one party. The SAQs themselves require you to attest that each of the service providers who are involved in your transaction processes are PCI compliant. If you cannot attest to this, you generally won’t be able to use the SAQ because there will be gaps in the requirements that have not been assessed.

There is no difference between the requirements in the SAQs and the requirements in the RoC. Only the reporting format differs.

You may be able to complete a SAQ yourself, or you may need assistance with it. Confide can help you understand the requirements and complete your SAQ regardless of your size. Sometimes you may be able to use a SAQ, but your stakeholders want some independence and assurance around the controls that they are signing off as complying with, and a QSA can provide that independent assurance through our SAQ assistance.

Report on Compliance

The Report on Compliance (RoC) template starts at 191 pages in v3.2.1 of the Standard. As mentioned before, the requirements themselves are the same. The main difference in the level of detail in the reporting. Each requirement in the RoC asks for verification of how the control was validated to be in place through a combination of interviews, configuration reviews, document reviews, and observations.

A RoC usually takes much longer to complete than a SAQ because of the amount of detail it requires. Even if you only are required to complete a SAQ, we recommend reviewing the ROC Reporting Template available from the PCI website to understand what kinds of information you should be asking about when you review your SAQ.

A RoC can only be completed by a QSA. Confide has extensive experience in completing RoCs in New Zealand, and if you need a RoC, contact us.

Supplemental Report on Compliance / Designated Entities Supplemental Validation

Appendix A3 sets out additional controls which may be required by a payment brand or an acquirer to provide additional validation and assurance that PCI DSS requirements and processes are maintained effectively and continuously. You only have to complete this appendix if it is requested by the payment brand(s) or banks.

The S-RoC / DESV is an additional 20 controls that build on the existing reporting in the RoC.

Attestation of Compliance

Regardless of what reporting requirements you have, part of those requirements will also include your Attestation of Compliance (AoC). The AoC summarises the findings in your SAQ or RoC and has a set of statements that your executive is required to attest to. If you have worked with a QSA on it, your QSA will also sign the AoC.

Need More Help?

If you need more help with your compliance, Confide can assist you at all the stages from scoping and PCI gap analysis through to completing a full independent assessment. Contact us for more information.

OVERVIEW

In April 2016, Version 3.2 of the Payment Card Industry Data Security Standard (PCI DSS) was released. This new version of the standard contains a number of new requirements which come into full force as of 1 February 2018. This document provides an overview of what is new in Version 3.2, separated by:

1. Clarification of requirements that came into force for all Version 3.2 reports.
2. New requirements that come into force for all parties (merchants and service providers) as of 1 February 2018.
3. New requirements that come into force for service providers only as of 1 February 2018.
4. Sunset date for SSL and Early TLS.

This document summarises what Confide has seen from assessments undertaken since Version 3.2 was released and the information that has been provided by the PCI Security Standards Council.

1. CLARIFICATION (APPLICABLE FOR ALL 3.2 REPORTS)

1.1.6.a: Identify the firewall and router configuration standards document(s) reviewed to verify the document(s) contain a list of all services protocols, and ports necessary, including a business justification and approval for each.

These approvals should be granted by someone other than a person who is responsible for managing the configuration. For example, this might include a Security Officer or other role who is responsible for overseeing the PCI DSS process internally, or by someone outside of the standard team of people who are responsible for performing the day to day management of network devices.

6.5: Address common coding vulnerabilities in software-development processes as follows:

• Train developers at least annually in up-to-date secure coding techniques, including how to avoid common coding vulnerabilities.
• Develop applications based on secure coding guidelines.

The requirement for developer training is not new. However, in Version 3.2, it was clarified that this training must take place for all developers at least annually. We also recommend that testers attend this training as well to ensure that they are adequately equipped to test for basic security vulnerabilities.

11.3.4.c: Verify that the [segmentation penetration test] was performed by a qualified internal resource or qualified external third party, and if applicable, the organisational independence of the tester exists (not required to be a QSA or ASV).

The requirement for segmentation testing is not new. However, in Version 3.2, a clarification was made that brings the requirement for how segmentation penetration testing into line with the requirements for internal and external penetration testing. The person performing the segmentation testing must be either a qualified internal resource or external third party, and there must be sufficient organisational independence (e.g. the penetration testing should not be done by individuals who are responsible for the day to day management of the systems or who report directly to staff who are responsible for these teams).

12.3.3: Verify that the usage policies define:

• A list of all critical devices, and
• A list of personnel authorised to use the devices

The wording of this requirement has been adjusted to ensure that it is clear that the usage policies must include both a list of the critical devices in the environment and a list of the personnel authorised to use the devices. This needs to be documented and cannot be considered “self-documenting” as part of a system such as Active Directory or LDAP.

2. NEW REQUIREMENTS FOR ALL PARTIES (AS OF 1 FEBRUARY 2018)

There are several new requirements that come into force for both merchants and service providers.

6.4.6: Upon completion of a significant change, all relevant PCI DSS requirements must be implemented on all new or changed systems and networks, and documentation updated as applicable.

To ensure that this requirement is met, Confide recommends that a clear definition of what constitutes a “significant change” be defined within the processes so that it is possible for staff to identify when this level of review is required. While the PCI Council does not provide a definitive definition of what constitutes a significant change, guidance from Requirement 11.2 suggests this includes (but is not limited to):

• New system component installations
• Changes in network topology
• Firewall rule modifications
• Product upgrades
• Operating system upgrades
• Sub-networks being added to the environment
• New web servers

Once significant changes have been defined, we recommend developing a set of templates for reviewing the relevant PCI DSS requirements to ensure that both (1) the relevant requirements have been put in place prior to the system going live, and (2) sufficient testing has been done to meet the requirements for PCI DSS (e.g. penetration testing, vulnerability scanning, etc.) Incorporating this into the change control process is one option.

8.3.1: Incorporate multi-factor authentication for all non-console access into the CDE for personnel with administrative access.

The PCI Security Standards Council recently published a guidance document on what constitutes multi-factor authentication (see: https://www.pcisecuritystandards.org/pdfs/Multi-Factor-Authentication-Guidance-v1.pdf).

In this document they provide a number of examples of what does and does not constitute multi-factor authentication and where multi-factor can be placed in the environment. We also recommend reviewing the PCI Security Standards Council’s guidance on Segmentation and Scoping (see:https://www.pcisecuritystandards.org/documents/Guidance-PCI-DSS-Scoping-and-Segmentation_v1.pdf) as the way that multi-factor is implemented may be influenced by how you have decided to segment the environment.

3. NEW SERVICE PROVIDER REQUIREMENTS (AS OF 1 FEBRUARY 2018)

These new requirements are currently only applicable to service providers. As defined by the PCI DSS, a service provider is any business that is directly involved in the processing, storage, or transmission of cardholder data on behalf of another organisation, or that otherwise impacts the security of cardholder data.

3.5.1: Maintain a documented description of the cryptographic architecture that includes:

• Details of all algorithms, protocols, and keys used for the protection of cardholder data, including key strength and expiry date
• Description of the key usage for each key
• Inventory of any HSMs and other SCDs used for key management

While policies and procedures for key management and the management of encryption devices has long been required, this requirement set out a new level of detail that must be documented around how cardholder data is protected. In part, this also helps the organisation to keep up with evolving threats to the architecture, and to be able to detect lost or missing keys or associated devices.

10.8: Implement a process for the timely detection and reporting of failures of critical security control systems, including but not limited to failure of:

• Firewalls
• IDS/IPS
• FIM
• Anti-virus
• Physical access controls
• Logical access controls
• Audit logging mechanisms
• Segmentation controls (if used)

This requirement is aimed at addressing the increased threat of intrusions going undetected for an extended amount of time. In order to ensure that there is a timely process for detecting failures in place, this requires a proactive process to be in place. There is not yet any clear guidance on what constitutes a timely manner. However, automated tools are likely to make this task significantly easier.

10.8.1: Respond to failures of any critical security controls in a timely manner. Processes for responding to failures in security controls must include:

• Restoring security functions
• Identifying and documenting the duration (date and time start to end) of the security failure
• Identifying and documenting cause(s) of failure, including root cause, and documenting remediation required to address root cause
• Identifying and addressing any security issues that arose during the failure
• Performing a risk assessment to determine whether further actions are required as a result of the security failure
• Implementing controls to prevent cause of failure from reoccurring
• Resuming monitoring of security controls.

While this requirement relates directly to the incidents identified in Requirement 10.8, this requirement relates to the incident management procedures and extends the procedures in the event that a critical security control fails. Due to the newness of this requirement and the extensive reporting requirements that go along with it, we recommend that this process is tested as part of the process development to ensure that the processes can be embedded within the incident processes for the organisation.

11.3.4.1: If segmentation is used, confirm PCI DSS scope by performing penetration testing on segmentation controls at least every six months and after any changes to segmentation controls/methods.

While this is a new requirement, it extends the exiting requirement for organisations that use segmentation to test the effectiveness of that segmentation. This new requirement increases the frequency with which service providers must perform this testing. While there is no requirement for the testing to be done by an external, third party, any internal party must be both (1) able to demonstrate that they are appropriately qualified to perform the testing, and (2) that they are organisationally independent.

12.4.1: Executive management shall establish responsibility for the protection of cardholder data and a PCI DSS compliance program to include:

• Overall accountability for maintaining PCI DSS compliance
• Defining a charter for a PCI DSS compliance program and communication to executive management.

The remaining new requirements are focused on the overarching governance processes to help ensure that PCI DSS is not treated as a point-in-time event, but instead is integrated into the BAU processes. As part of that, there needs to be a commitment at the senior level to ensure that PCI DSS is visible at the executive level.

12.11: Perform reviews at least quarterly to confirm personnel are following security policies and operational procedures. Reviews must cover the following processes:

• Daily log reviews
• Firewall rule-set reviews
• Applying configuration standards to new systems
• Responding to security alerts
• Change management processes

This requirement and Requirement 12.11.1 help to ensure that processes are regularly reviewed to ensure that they are being followed. While this requirement is not meant to repeat the testing from the PCI DSS requirements, understanding the underlying intention of each of these requirements should guide how the review process is carried out. This also helps to ensure that failures in processes can be identified early, so as to minimise the risk to PCI DSS compliance.

12.11.1: Maintain documentation of quarterly review processes to include:

• Documenting results of the reviews
• Review and sign off of results by personnel assigned responsibility for the PCI DSS compliance program.

This requirement ties together the review documentation from Requirement 12.11 and the governance processes from Requirement 12.4, and helps to ensure that there is a clear visibility into how processes that affect PCI DSS compliance are visible to senior management.

4. TLS REQUIREMENTS (1 JULY 2018)

After 30 June 2016, all service providers must offer a secure protocol (e.g. TLS 1.2) as an option.

After 30 June 2018, all merchants and service providers must only use a secure protocol for the transmission of cardholder data (e.g. TLS 1.2) and all insecure versions (e.g. SSL and early TLS) must be disabled.

Prior to 30 June 2018, existing implementations that use SSL and/or early TLS must have a formal Risk Mitigation and Migration Plan in place.

Appendix 2 covers the requirements for SSL / Early TLS.

Given the impending deadline for disabling SSL and Early TLS, we recommend that reviewing the current need for these protocols is done on a more frequent basis to determine if it is possible to disable them prior to the deadline.