myth… Not a risk-based standard

From its inception in 2004, PCI DSS has been inherently risk-based. The standard was developed by consolidating existing security programs operated by the major card brands into a unified, global standard to address weaknesses throughout the payments lifecycle. Its requirements established mandatory mitigation steps for merchants and service providers to reduce the risks associated with card payments. Until PCI DSS 4.0, organizations have not had any flexibility to define that risk for themselves.

In PCI DSS 4.0, while unable to risk-accept themselves out of the requirement to meet all applicable standard controls, organizations have some flexibility to establish control testing frequencies through targeted risk assessment (PCI DSS 12.3).

myth… all about technology

While technological security controls are present across all the standard requirements, PCI DSS is and never has been a technology standard. It mandates control to address risks associated with people, processes, and technology relating to card payments and account data security. V4.0 emphasizes this even more strongly than in previous versions, with the first and second controls of each key requirement focused on defining security policy and documenting roles and responsibilities, respectively.

myth… compliance means security

An effective compliance program that focuses on continuous improvement and is embedded in business-as-usual activities will improve an organization’s overall security posture. But compliance cannot guarantee security. PCI DSS 4.0 places even greater emphasis on compliance as a continuous process than in previous versions, highlighting the value of incorporating compliance monitoring in BAU processes to identify control weaknesses and anomalies before they result in an incident, breach, or compliance failure.

Organizations that choose to expand the implementation of controls to protect other personal and sensitive data environments (even where these are out-of-scope for PCI DSS) will achieve greater security benefits from compliance than those that exclude them.

myth… doesn’t work with evolving technologies

As technology evolves, so do the ways organizations manage and operate their businesses. Previous versions of the standard defined the controls organizations had to implement to comply. Increasing migration toward cloud services, software-defined networking, and other innovations have changed the architecture of business networks, management of user access, and data management provisions. PCI DSS 4.0 supports the rapid evolution of technology with far greater flexibility than previous versions. The Customized Approach allows organizations to meet controls using a wider variety of technological and operational controls to meet the objective — the outcome — of its equivalent defined control.

myth… scoping is only relevant for first-time compliance

Scoping is the first stage of any compliance program, but it’s also crucial to maintaining compliance over time too. PCI DSS assessors have always had to validate and document scope in the Executive Summary of a Report on Compliance (ROC), and self-assessments have always required organizations to attest that their scope meets the Self-Assessment Questionnaire (SAQ) eligibility criteria.

PCI DSS 4.0 requires organizations to verify their scope every 6 or 12 months, depending on whether they are merchants or service providers (PCI DSS 12.5). Organizations can automate this process with periodic data discovery scanning while supporting compliance with 26 other controls across the standard.

Want to keep up with all our blog posts? Subscribe to our newsletter!

Subscribe