PCI DSS 3.2 & 3.2.1 New PCI Requirements for Service Providers: What You Should Know

* PCI 4.0 is now the latest version of the PCI DSS

Learn what PCI requirements service providers need to fulfill.

The PCI Council released PCI DSS 3.2 in April 2016, which introduced several new requirements for service providers. On February 1, 2018, these new requirements became mandatory for compliance. Then in May of 2018, the council released PCI DSS 3.2.1. This latest version does not add or remove any requirements for service providers.

Here’s a quick look at the requirements that became mandatory in 2018, and what service providers are expected to do to follow them.

New Requirements for Service Providers

Cryptographic architecture (3.5.1)

Service providers need to maintain a documented description of cryptographic architectures, including:

• 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

You should keep up with evolving threats to your architecture by planning for and documenting updates (e.g., different algorithms/key strengths changes). Maintaining documentation helps you detect lost or missing keys or key-management devices, and identify unauthorized changes to your cryptographic architecture.

See also: PCI DSS Requirement 3: What You Need to be Compliant

Timely detection and reporting (10.8, 10.8.1)

Service providers are required to implement a timely detection and alerting process to identify failure of a critical security control systems.

Examples of critical security control systems include:

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

Service providers need to 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 from the security failure
• Implementing controls to prevent cause of failure from reoccurring
• Resuming monitoring of security control

Establish responsibilities for PCI and Data (12.4.1)

Executive management needs to establish responsibility for the protection of card-holder 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

Smaller organizations should add these roles to an individual’s job responsibilities, while larger organizations might need to establish a PCI compliance team (e.g., a compliance team made up of IT, accounting, and management).

Whichever is the case, management should give their PCI officer/team power to act and implement necessary changes to become PCI DSS compliant, as well as have at least monthly meetings with executive management to report on progress.

See also: What are Service Provider Levels and How Do They Affect PCI Compliance?

Quarterly Personnel Reviews (12.11, 12.11.1)

Service providers need to 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

In addition, you need to maintain documentation of quarterly review process, including:

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

These reviews help to ensure that security policies and procedures are being followed as expected. Keep records, including dates and findings of these quarterly reviews.

Penetration testing (11.3.4.1)

Service providers who use segmentation to isolate the cardholder data environment from other networks must perform penetration testing on segmentation controls at least every 6 months and after any changes to segmentation controls/methods.

This penetration testing should be performed by a qualified internal resource or third party. If an internal resource is used, the tester should have organizational independence (though they aren’t required to be a QSA or ASV). The purpose of penetration testing segmentation controls/methods is to verify that the cardholder data environment is protected from unauthorized access.

See also: New 3.2 Requirements for Penetration Testing and Segmentation: What You Don’t Know