ControlScan Utilize by NCB: FAQs PCI Compliance
Protect Your Business And Your Customers From Fraud With Best-In-Class Security Solutions
PCI DSS Merchant Compliance REQUIRED
OVERVIEW
The Payment Card Industry’s Data Security Standards (PCI-DSS) provides guidelines for the safety and security of cardholder data across the globe. These standards are designed to prevent theft and fraudulent use of cardholder data and compliance with these regulations are mandatory internationally.
As a merchant who accepts payments via debit and credit cards, you are required BY NCB to complete a Merchant Compliance programme to demonstrate that you are compliant with the established Data Security Standards. To assist with this, NCB have engaged an external partner, ControlScan. You must contact your NCB Representative who will provide further information on how to complete this programme after your merchant integration for the NEW FAC/NCB 3DS2 integration -- Powertranz gateway system has been completed as well as the activation of your PAID firewall service with HBJamaica. As required by NCB external partner, ControlScan, you MUST have a firewall service active for your web store. See details below.
Changes to Self-Assessment Questionnaires for PCI DSS 4
PCI DSS v4.0 introduced some changes to each of the self-assessment questionnaires (SAQs). Below is a summary table showing the SAQs and the number of requirements for each of the related PCI DSS versions.
Although it seems there are less v4.0 requirements, many of the sub-requirements in v3.2.1 have been kept and are in a bullet list with a single tick box for the requirement. Organisations still need to address each of the specific bullet points in each requirement and perform each of the bullet points in the expected testing.
Number of requirements for each SAQs for PCI DSS v3.2.1 and PCI DSS v4.0
SAQ V3.2.1 Reqs. v4.0 Reqs. Eligibility Criteria Additional Information SAQ A 24 31 All storage, processing and transmission of account data outsourced E-commerce websites still have requirements that apply to the web server SAQ A-EP 192 151 All processing of account data outsourced except for the payment page CDE requirements apply to the e-commerce websites SAQ B 41 27 Dial-up payment terminals only Not for network connected payment terminals SAQ B-IP 87 49 Standalone payment terminals on isolated network B-IP requiring network controls and isolation means P2PE is a better option SAQ P2PE 33 21 Payments via payment terminals from a validated P2PE solution All controls are implemented from the P2PE instruction Manual SAQ C 161 132 Payment applications such as POS that are isolated from other systems Isolation can be done through network segmentation SAQ C-VT 84 54 Virtual payment terminal (such as web browser on a PC) isolated from other systems Isolation can be done through network segmentation SAQ D Merchants 330 252 Merchants not eligible for other SAQs Some controls may not be applicable SAQ D Service Providers 369 278 All service providers (service providers are not eligible for merchant SAQs) Some controls may not be applicable General SAQ Changes
Organisations that utilize the NEW FAC/NCB 3DS2 integration -- Powertranz gateway system MUST start using v4.0 now. Requirements marked with an asterisk (*) in each of the following SAQ sections are important new requirements.
The SAQs now define Account Data, which is Cardholder Data (CHD) and/or Sensitive Authentication Data (SAD). PCI DSS covers organisations that store, process or transmit Account Data. Regardless of the SAQ, merchants should understand the scope of the PCI DSS requirements which is defined in section 4 of the document PCI DSS Requirements and Testing Procedures v4.0.
A new response option is In Place with Remediation, which adds to the response options: In Place, In Place with CCW, Not Applicable, and Not In Place. This should be selected if a requirement has not been met during the expected testing but was then implemented, re-tested and found to then be in place. Additionally, Appendix C of the SAQs requires documented explanation of why requirements were not initially in place.
Although PCI DSS allows a custom approach for many of the requirements, this is not allowed for self-assessments. Each of the requirements must be met if they are applicable, although Compensating Controls can still be used for legitimate technical or business constraints.
SAQ A
SAQ A is for merchants that outsource all storage, processing, and transmission of account data. The SAQ A eligibility criteria now require specific checking of the compliance of third-party service providers (TPSPs) through their Attestations of Compliance (AOCs), and that the AOCs cover services used by the merchant.
SAQ A changes for ecommerce are explained in the separate article PCI DSS 4 – E-commerce Changes for SAQ A Explained. Apart from those significant changes for e-commerce, there are no other changes in SAQ A for those that outsource all storage, processing, and transmission of account data.
SAQ A-EP
SAQ A-EP is for e-commerce merchants outsource all storage, processing and transmission of account data except that they control the website payment page. If you are using the HBCommerce system, this is your current status.
As with SAQ A, the SAQ A-EP eligibility criteria now requires specific checking of the compliance of TPSPs through their AOCs, and that the AOCs cover services used by the merchant. TPSPs would include the e-commerce payment service providers. Further to that, most new requirements that are significant (signified by an asterisk), and are as follows:
Requirement 3.2.1* adds that merchants are responsible for determining how TPSPs meet this requirement for account data retention. Requirement 3.3 clarifies that SAD storage applies to any account data stored on paper.
Requirement 6.3.2 now requires an inventory of bespoke and custom software and third-party software components.
Requirement 6.4.3* requires that you manage script files like JavaScript that are included on payment pages that the merchant hosts; for example, Google Analytics, third-party advertising scripts, or CDN hosted scripts, are especially important.
Requirement 6.4.2 will require an automated solution to protect web applications such as a web application firewall; this was one of two options in PCI DSS v3.2.1 and becomes the only option from the end of Q1 2025.
Requirement 7.2.4* needs at least six-monthly user account access reviews.
Section 8 now includes a new password and reset password controls in 8.3.5*, as well as a minimum of 12 alphanumeric characters for passwords in 8.3.6*, and MFA enforced for all access to the CDE in 8.4.2*. With e-commerce websites, it is likely that organisations already enforce MFA for all access to the CDE. There are additional requirements for application or system accounts in 8.6 restricting the use of interactive application accounts, no hardcoding of passwords, and periodic changes: again, mandatory from Q1 2025.
Section 9.4 clarifies that media applies to merchants with paper records that may contain account data.
Requirement 10.4.1.1* now requires that automated mechanisms are used to perform audit log reviews, not manual, which is allowed in v3.2.1.
Requirement 11.6.1* needs a change and tamper detection mechanism for the payment pages on the web servers. This requirement needs careful consideration, and there are some solutions described in the guidance column within PCI DSS v4.0 for this requirement.
Requirement 12.3.1* requires targeted risk analysis on any requirement with flexible frequency, such as 5.2.3.1, 5.3.2.1, 8.6.3, 10.4.2.1 and 11.6.1. This requires comprehensive and specific documentation.
Requirement 12.6.3.1* needs security awareness training to include awareness of phishing and social engineering attacks.
Requirement 12.10.1 for an incident response plan has guidance that 12.10.1 means that the merchant has documented an incident response and escalation plan to be used for emergencies, consistent with the size and complexity of the merchant’s operations. 12.10.3 mandates that specific personnel are designated to be available on a 24/7 basis to respond to suspected or confirmed security incidents.
Was this answer helpful?
Also Read
Powered by WHMCompleteSolution