As we complete the 3rd hour of the meeting discussing PCI scope, the customer turns to me and asks, “So what’s the minimum that I need to do to pass PCI?”
In almost all initial engagements as QSAs, PA-QSAs, and P2PE QSAs, one common question that we are asked is “What’s the minimum I need to do for PCI?”. The answer to this question can be frustrating for both the QSA and the client, because the answer is neither simple nor straight forward.
PCI DSS is a security framework which has a focus on an organization’s credit card processing operations. The requirements and scope are dictated by where an organization stores, processes and transmits credit cards, however it also includes the secondary systems and third parties that connect to, or may impact the security of, the environment where credit cards are used. It does not define all security controls an organization should have in place. Rather is looks at specific security controls and procedures to ensure that credit cards are handled in a secure manner.
As organizations become more aware of security and the fundamental role it plays throughout the enterprise, a new level of maturity begins to ensure that security processes, technologies and policies become engrained in the DNA of the organization. What many organizations do not realize is that once you have achieved PCI DSS compliance, invariably the enterprise will follow. Since organizational policies, standards and operational processes are modified to align to PCI DSS, the downstream effect is that all organizational systems, applications, business and IT operational processes are also reviewed and transformed.
The conversation then moves from “What’s the minimum for PCI?” to “Why are we not doing this for everything?” Which is the right direction of maturity.
An example I can share is an organization which stood up 2 environments for remote access.
The first environment was managed according to the requirements and processes that security required which also aligned to PCI DSS. This environment was solely used as the remote jump point into the cardholder data environment.
The second environment was initially created as identical to the first remote access environment; however, it was not bound by the same security “rules” as the first environment and was used as the remote jump point to access all non-cardholder data environment systems.
Long story short, within 6 months, the first environment was operational and had little to no functional problems. It was properly maintained with the correct change control, access management, no-repudiation and rigour that the security team wanted to implement within the organization. The second environment had issues with incorrect versions of software, additional/unapproved tools and software installed, and little to no tracking of activities that occurred within the environment, the system had become unstable and non-functional. It was decided to rebuild the environment from scratch and apply the same level of security rigour as the first environment. This example demonstrates how security controls can help an organization to reduce operational costs when adhered to.
Organizations need to spend less effort making PCI DSS compliance a project, and take the approach to modify, enhance or transform their current security processes and strategies to embrace any security framework that is required within their industry, whether it be PCI DSS, ISO 27001, PIPDEA, HIPA, GDPR, NIST or ITIL. The most mature organizations understand that security operations have a seat at the table help shape the direction and focus of the organization. The journey to compliance may be longer, but the effort pays dividends in the end. It has been our experience that organizations that embed security and compliance into their business as usual processes are more resilient to accepting changes in the business, more in tune with risks and threats to their organization, and better prepared to respond to their customers concerns.