The Payment Card Industry Data Security Standard (PCI DSS) has provided a common framework of technical and operational requirements for protecting cardholder account data. If your company, products, services, or even partners are involved in payment card processing, the PCI DSS applies to you. Annual assessments for compliance are required, while non-compliance may result in fines, increased transaction costs, and other consequences related to a failed audit or high-risk data breach.
What Counts as In Scope
PCI DSS requirements apply to every system component included in, connected to, or capable of affecting the cardholder data environment. That environment is defined as all the people, processes, and technologies that store, process, or transmit account data.
Account data means two things. Cardholder data covers the primary account number, the cardholder name, the expiration date, and the service code. Sensitive authentication data covers full track data from the magnetic stripe or its chip equivalent, the CAV2, CVC2, CVV2 or CID value, and PINs and PIN blocks. The primary account number is the defining factor. An organization that stores, processes, and transmits neither PANs nor sensitive authentication data is not subject to the standard at all.
System components reach further than most people expect. Depending on size, digital maturity, and role in card processing, they can include network devices, servers, virtual machines, desktop and mobile computers, wireless technology, and applications. They can sit in development, test, production, or backup and recovery environments, on premises or in the cloud. Wherever account data exists or travels, and whatever touches or affects that environment, is in scope.
Defining Scope Is Not the Same as Confirming It
The scope has to be confirmed and documented before an assessment can properly begin, and that is four distinct pieces of work.
First, identify and document every instance of cardholder data in the environment, to verify that none exists outside the boundary as drawn. Second, remediate anything found outside it, by deleting the data, migrating it inside, or redrawing the boundary to include it. Third, identify and document every flow of cardholder data, along with any system connected to the environment or capable of affecting it if compromised. Fourth, give the assessor the documentation, such as a data-flow diagram and an inventory, showing how the scope was determined and confirmed.
The guidance suggests that documentation can serve as a reference for the following year. In practice it rarely does. Technology changes, connectivity grows, and data volumes grow faster, so scoping tends to become a start-from-scratch exercise every year. The alternative most organizations fall into is worse: the scope quietly becomes the entire extended enterprise. Both carry real cost and real risk.
Why Data-Driven Businesses Struggle With It
The more data an organization stores, uses, and shares in pursuit of competitive advantage, the more likely it is to lose track of the sensitive parts. Without proper controls, sensitive data can end up almost anywhere, in almost any format. That is the problem scope management has to solve, and it is why the work belongs in the whole year rather than in the weeks before an assessment.
Learn how you can minimize risk and cost using smarter scope management and:
- How to define the scope of PCI DSS assessments
- Confirming and documenting the scope, in addition to managing all year long
- How to reduce the risks and costs of PCI compliance