PCI SSC European Community Meeting 2022
Lessons from a Community, 18–20 October 2022
For the first time in three years, the European payments community gathered in Milan for the PCI SSC Community Meeting from 18–20 October. The event delivered a packed agenda including dedicated sessions for assessors and participating organizations.
The newly released version 4.0 of the Data Security Standard (PCI DSS) provided the focus for Security Standards Council (PCI SSC) speakers, and there were many golden nuggets of advice shared across the case studies and deep-dive sessions presented by members of the payments community.
Here, we offer up our top five takeaways from the Community Meeting. The first three relate to the new version of the standard, while the last two are examples of how PCI DSS can be used to improve security by leveraging its requirements beyond the formal scope of the standard.
1. PCI DSS 4.0 protects more than the PAN
Previous versions of the PCI DSS focused on protecting cardholder data associated with the PAN. However, it’s long been understood that the standard can be used to protect against threats and secure other elements in the payments ecosystem.
In PCI DSS 4.0, language has been incorporated into the standard for environments using data elements that relate to payments but that don’t use PAN or SAD information.
2. Remediation for “Remediation in place” in ROC reporting
The initial reporting template released with the updated DSS introduced a new compliance status, “Remediation in place.” The intent of this new status was to enable reporting where an assessor identifies a non-compliance, and the organization addresses the issue before the assessment is complete.
At both the North America and European Community Meetings, the SSC received concerned feedback from the community that, while recognising the value and intent of the addition, it may present issues for cyber insurance, as well as customer and client relationships.
To resolve this, the SSC is removing the status from its reporting templates and attestation documents. Instead, a separate worksheet template will be developed for QSAs to use with clients.
3. Documenting a targeted risk analysis
Along with hugely enhanced guidance information throughout the standard, the SSC has produced templates for organizations to support controls requiring a targeted risk analysis.
The targeted risk analysis replaces the organizational risk assessment requirement of previous versions of the standard. There are two scenarios where organizations need to perform a targeted risk analysis: for evaluating the frequency of control testing (12.3.1), and for designing controls as part of the Customized Approach (12.3.2).
A targeted risk analysis template can be found in Appendix E2 of PCI DSS 4.0. While written to support the targeted risk analysis for controls designed using the Customized Approach, this template can be adapted to meet requirement 12.3.1 where a risk analysis is required to establish the frequency of control testing where the standard allows flexibility.
Appendix E1 provides the template for documenting controls designed using the Customized Approach, while Appendix C provides the template for Compensating Controls for use with the Defined Approach.
Other useful documents now available via the PCI SSC document library are:
- PCI DSS Quick Reference Guide v4.0
- Prioritized Approach for PCI DSS 4.0
- Prioritized Approach Tool v4.0
4. Integrating PCI DSS into zero-trust and other security frameworks
PCI DSS is one of many security standards organizations may be required to maintain. The challenge of managing compliance against an ever-expanded set of obligations – whether strategic, contractual or legal and regulatory – is one faced by many organizations.
The best way to address this is by integrating the control requirements of PCI DSS into other security frameworks of good practice. The controls defined in the PCI DSS are complementary to standards such as ISO27001, SSAE 18 or the NIST Cybersecurity Framework and can be aligned with Zero-Trust principles for security. PCI DSS controls can also be used to meet the data security requirements of legislation such as GDPR, PSD2, CCPA, etc.
Using PCI DSS controls to satisfy other security and data protection obligations means that the standard becomes part of an integrated, holistic security management system rather than a siloed operation. This reduces the compliance overheads associated with PCI DSS while providing a higher level of security control across the organization.
5. Scoping for security, not just compliance
Scoping for PCI DSS has always been a precursor to compliance. To begin a compliance program, organizations need to understand and define their scope – the people, processes and system components involved in the handling of account data.
With PCI DSS 4.0, organizations are required to validate their scope at least every 12 months (for service providers, it’s every 6 months; for DESVs, it’s every 3 months).
Effective scoping isn’t just important for the organization’s own compliance activities, but also for those supported by external parties such as penetration testing. A penetration test is a real-world attempt to access a company’s systems by a trusted individual or third party. It’s an important activity for testing external and internal security controls and highlighting any weaknesses that could be exploited.
The value of a penetration test for PCI DSS relies on a well-defined scope. If an organization wants to maximise the benefit of testing, it needs to invest in ensuring its scope is up-to-date and comprehensive.
Verifying scope starts with data discovery: identifying all the places account data exists in the organization. From the data, organizations can verify the accuracy of their system inventories and data flows, as well as identifying any unexpected repositories of account data.
Data discovery can also be used to identify other forms of valuable or sensitive data including (for example) account credentials within software repositories or system logs. This type of information is valuable to malicious actors who can use it to access system accounts that enable a successful attack. While not formally part of a PCI DSS scope, this kind of discovery activity helps to identify unknown areas of risk so that they can be resolved before an incident occurs.
Start your journey of discovery with Ground Labs today!
Want to keep up with all our blog posts? Subscribe to our newsletter!Subscribe